summaryrefslogtreecommitdiff
path: root/Documentation/git-merge-base.txt
AgeCommit message (Collapse)AuthorFilesLines
2018-10-23doc: fix ASCII art tab spacingLibravatar Andreas Heiduk1-3/+3
Followup to 5dd05ebf ("doc: fix merge-base ASCII art tab spacing", 2016-10-21) Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-09merge-base --fork-point doc: clarify the example and failure modesLibravatar Junio C Hamano1-8/+56
The illustrated history used to explain the `--fork-point` mode named three keypoint commits B3, B2 and B1 from the oldest to the newest, which was hard to read. Relabel them to B0, B1, B2. Also illustrate the history after the rebase using the `--fork-point` facility was made. The text already mentions use of reflog, but the description is not clear what benefit we are trying to gain by using reflog. Clarify that it is to find the commits that were known to be at the tip of the remote-tracking branch. This in turn necessitates users to know the ramifications of the underlying assumptions, namely, expiry of reflog entries will make it impossible to determine which commits were at the tip of the remote-tracking branches and we fail when in doubt (instead of giving a random and incorrect result without even warning). Another limitation is that it won't be useful if you did not fork from the tip of a remote-tracking branch but from in the middle. Describe them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21doc: fix merge-base ASCII art tab spacingLibravatar Philip Oakley1-13/+13
The doc-tool stack does not always respect the 'tab = 8 spaces' rule, particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base and the Git generated html pages. Use just spaces within the block of the ascii art. Noticed when reviewing Junio's suggested update to `git merge-base` https://public-inbox.org/git/xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com/T/#u Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-29merge-base: teach "--fork-point" modeLibravatar Junio C Hamano1-2/+36
The "git pull --rebase" command computes the fork point of the branch being rebased using the reflog entries of the "base" branch (typically a remote-tracking branch) the branch's work was based on, in order to cope with the case in which the "base" branch has been rewound and rebuilt. For example, if the history looked like this: o---B1 / ---o---o---B2--o---o---o---Base \ B3 \ Derived where the current tip of the "base" branch is at Base, but earlier fetch observed that its tip used to be B3 and then B2 and then B1 before getting to the current commit, and the branch being rebased on top of the latest "base" is based on commit B3, it tries to find B3 by going through the output of "git rev-list --reflog base" (i.e. Base, B1, B2, B3) until it finds a commit that is an ancestor of the current tip "Derived". Internally, we have get_merge_bases_many() that can compute this with one-go. We would want a merge-base between Derived and a fictitious merge commit that would result by merging all the historical tips of "base". When such a commit exist, we should get a single result, which exactly match one of the reflog entries of "base". Teach "git merge-base" a new mode, "--fork-point", to compute exactly that. Helped-by: Martin von Zweigbergk <martinvonz@gmail.com> Helped-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-31merge-base: "--is-ancestor A B"Libravatar Junio C Hamano1-0/+28
In many scripted Porcelain commands, we find this idiom: if test "$(git rev-parse --verify A)" = "$(git merge-base A B)" then ... A is an ancestor of B ... fi But you do not have to compute exact merge-base only to see if A is an ancestor of B. Give them a more direct way to use the underlying machinery. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-04Merge branch 'vr/merge-base-doc'Libravatar Junio C Hamano1-13/+21
* vr/merge-base-doc: Restructure documentation for git-merge-base. Documentation: update to git-merge-base --octopus
2011-04-15Restructure documentation for git-merge-base.Libravatar Jonathan Nieder1-12/+16
Restructure the text of git-merge-base to better explain more clearly the different modes of operation. Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: update to git-merge-base --octopusLibravatar Vincent van Ravesteijn1-1/+5
Unlike plain merge-base, merge-base --octopus only requires at least one commit argument; update the synopsis to reflect that. Add a sentence to the discussion that when --octopus is used, we do expect '2' (the common ansestor across all) as the result. Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-8/+0
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
2010-08-18merge-base --independent to print reduced parent list in a mergeLibravatar Jonathan Nieder1-0/+9
While show-branch --independent does not support more than MAX_REVS revs, git internally supports more with a different algorithm. Expose that functionality as "git merge-base --independent". This should help scripts to catch up with builtin merge in supporting dodecapus. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18merge-base --octopus to mimic show-branch --merge-baseLibravatar Jonathan Nieder1-7/+12
While show-branch --merge-base does not support more than MAX_REVS revs, git supports more with a different algorithm (v1.6.0-rc0~51^2~13, Introduce get_octopus_merge_bases() in commit.c, 2008-06-27). Expose that functionality. This should help scripts to catch up with builtin merge in supporting dodecapus. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18Documentation: add a SEE ALSO section for merge-baseLibravatar Jonathan Nieder1-0/+6
For example, a person reading the merge-base man page might wonder about the fastest way to check if one commit is an ancestor of another (which would require rev-list). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05git-merge-base/git-show-branch --merge-base: Documentation and testLibravatar Michael J Gruber1-0/+4
Currently, the documentation suggests that 'git merge-base -a' and 'git show-branch --merge-base' are equivalent (in fact it claims that the former cannot handle more than two revs). Alas, the handling of more than two revs is very different. Document this by tests and correct the documentation to reflect this. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05git-merge-base/git-show-branch: Cleanup documentation and usageLibravatar Michael J Gruber1-2/+3
Make sure that usage strings and documentation coincide with each other and with the actual code. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-09Improve language in git-merge.txt and related docsLibravatar Ralf Wildenhues1-10/+9
Improve some minor language and format issues like hyphenation, phrases, spacing, word order, comma, attributes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-29documentation: merge-base: explain "git merge-base" with more than 2 argsLibravatar Junio C Hamano1-11/+66
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-2/+2
The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation formatting and cleanupLibravatar Jonathan Nieder1-4/+4
Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-2/+2
Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06documentation: move git(7) to git(1)Libravatar Christian Couder1-1/+1
As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-1/+1
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-01-18Documentation: sync git.txt command list and manual page titleLibravatar Junio C Hamano1-1/+1
Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Update the documentation for git-merge-baseLibravatar Fredrik Kuivinen1-4/+14
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10Remove the version tags from the manpagesLibravatar Junio C Hamano1-1/+0
Signed-off-by: Christian Meder <chris@absolutegiganten.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-20[PATCH] Documentation: Update all files to use the new gitlink: macroLibravatar Sergey Vlasov1-1/+1
The replacement was performed automatically by these commands: perl -pi -e 's/link:(git.+)\.html\[\1\]/gitlink:$1\[1\]/g' \ README Documentation/*.txt perl -pi -e 's/link:git\.html\[git\]/gitlink:git\[7\]/g' \ README Documentation/*.txt Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-05-10[PATCH 1/4] split core-git.txt and updateLibravatar David Greaves1-0/+34
Split the core-git.txt file Formatting fix to the diff-format.txt Signed-off-by: David Greaves <david@dgreaves.com>