path: root/Documentation/git-merge-base.txt
AgeCommit message (Collapse)Author
2019-09-09git-merge-base.txt: render indentations correctly under AsciidoctorMartin Ågren
There are several graphs in this document. For most of them, we use a single leading tab to indent the whole graph, and then we use spaces (possibly eight or more) to align things within the graph. In the larger graph, we use a different strategy: We use 1-N tabs and just a small number of spaces (<8). This is how we usually prefer to do our indenting, but Asciidoctor ends up rendering this differently from AsciiDoc. Same thing for the if-then-fi examples where the conditional code is indented by two tabs, which renders differently under AsciiDoc and Asciidoctor. Similar to 379805051d ("Documentation: render revisions correctly under Asciidoctor", 2018-05-06), use an explicit literal block to indicate that we want to keep the leading whitespace in the tables. Change not just the ones that render differently, but all of them for consistency. Because this gives us some extra indentation, we can remove the one that we have been carrying explicitly. That is, drop the first tab of indentation on each line. With AsciiDoc, this results in identical rendering before and after this commit, both for git-merge-base.1 and git-merge-base.html. A less intrusive change would be to replace tabs 2-N on each line with eight spaces. But let's follow the example set by 379805051d, so that we can use our preferred way of indenting. Signed-off-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2019-04-02doc: promote "git switch"Nguyễn Thái Ngọc Duy
The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... The "Checking out files" progress line in unpack-trees.c is also updated to "Updating files" to be neutral to both git-checkout and git-switch. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-10-23doc: fix ASCII art tab spacingAndreas Heiduk
Followup to 5dd05ebf ("doc: fix merge-base ASCII art tab spacing", 2016-10-21) Signed-off-by: Andreas Heiduk <> Signed-off-by: Junio C Hamano <>
2017-11-09merge-base --fork-point doc: clarify the example and failure modesJunio C Hamano
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 <>
2016-10-21doc: fix merge-base ASCII art tab spacingPhilip Oakley
The doc-tool stack does not always respect the 'tab = 8 spaces' rule, particularly the git-scm doc pages 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` Signed-off-by: Philip Oakley <> Signed-off-by: Junio C Hamano <>
2013-10-29merge-base: teach "--fork-point" modeJunio C Hamano
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 <> Helped-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2012-08-31merge-base: "--is-ancestor A B"Junio C Hamano
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 <>
2011-05-04Merge branch 'vr/merge-base-doc'Junio C Hamano
* 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.Jonathan Nieder
Restructure the text of git-merge-base to better explain more clearly the different modes of operation. Signed-off-by: Vincent van Ravesteijn <> Signed-off-by: Junio C Hamano <>
2011-04-15Documentation: update to git-merge-base --octopusVincent van Ravesteijn
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 <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-03-11doc: drop author/documentation sections from most pagesJeff King
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 mergeJonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2010-08-18merge-base --octopus to mimic show-branch --merge-baseJonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2010-08-18Documentation: add a SEE ALSO section for merge-baseJonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2009-08-05git-merge-base/git-show-branch --merge-base: Documentation and testMichael J Gruber
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 <> Signed-off-by: Junio C Hamano <>
2009-08-05git-merge-base/git-show-branch: Cleanup documentation and usageMichael J Gruber
Make sure that usage strings and documentation coincide with each other and with the actual code. Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2008-12-10Improve language in git-merge.txt and related docsRalf Wildenhues
Improve some minor language and format issues like hyphenation, phrases, spacing, word order, comma, attributes. Signed-off-by: Junio C Hamano <>
2008-07-30documentation: merge-base: explain "git merge-base" with more than 2 argsJunio C Hamano
Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2008-07-05manpages: italicize git command names (which were in teletype font)Jonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2008-07-02Documentation formatting and cleanupJonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2008-07-02Documentation: be consistent about "git-" versus "git "Jonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2008-06-06documentation: move git(7) to git(1)Christian Couder
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 <> Signed-off-by: Junio C Hamano <>
2008-01-07Documentation: rename gitlink macro to linkgitDan McGee
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 <> Signed-off-by: Junio C Hamano <>
2007-06-07War on whitespaceJunio C Hamano
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 <>
2007-01-18Documentation: sync git.txt command list and manual page titleJunio C Hamano
Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <>
2006-05-16Update the documentation for git-merge-baseFredrik Kuivinen
Signed-off-by: Fredrik Kuivinen <> Signed-off-by: Junio C Hamano <>
2005-10-10Remove the version tags from the manpagesJunio C Hamano
Signed-off-by: Christian Meder <> Signed-off-by: Junio C Hamano <>
2005-09-20[PATCH] Documentation: Update all files to use the new gitlink: macroSergey Vlasov
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 <> Signed-off-by: Junio C Hamano <>
2005-05-10[PATCH 1/4] split core-git.txt and updateDavid Greaves
Split the core-git.txt file Formatting fix to the diff-format.txt Signed-off-by: David Greaves <>