summaryrefslogtreecommitdiff
path: root/Documentation/git-merge-base.txt
Commit message (Collapse)AuthorAgeFilesLines
* merge-base: teach "--fork-point" modejc/merge-base-reflogJunio C Hamano2013-10-291-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>
* merge-base: "--is-ancestor A B"Junio C Hamano2012-08-311-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>
* Merge branch 'vr/merge-base-doc'Junio C Hamano2011-05-041-13/+21
|\ | | | | | | | | | | * vr/merge-base-doc: Restructure documentation for git-merge-base. Documentation: update to git-merge-base --octopus
| * Restructure documentation for git-merge-base.Jonathan Nieder2011-04-151-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>
| * Documentation: update to git-merge-base --octopusVincent van Ravesteijn2011-04-151-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>
* | doc: drop author/documentation sections from most pagesJeff King2011-03-111-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.
* merge-base --independent to print reduced parent list in a mergeJonathan Nieder2010-08-181-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>
* merge-base --octopus to mimic show-branch --merge-baseJonathan Nieder2010-08-181-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>
* Documentation: add a SEE ALSO section for merge-baseJonathan Nieder2010-08-181-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>
* git-merge-base/git-show-branch --merge-base: Documentation and testMichael J Gruber2009-08-051-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>
* git-merge-base/git-show-branch: Cleanup documentation and usageMichael J Gruber2009-08-051-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>
* Improve language in git-merge.txt and related docsRalf Wildenhues2008-12-091-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>
* documentation: merge-base: explain "git merge-base" with more than 2 argsJunio C Hamano2008-07-291-11/+66
| | | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* manpages: italicize git command names (which were in teletype font)Jonathan Nieder2008-07-051-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>
* Documentation formatting and cleanupJonathan Nieder2008-07-011-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>
* Documentation: be consistent about "git-" versus "git "Jonathan Nieder2008-07-011-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>
* documentation: move git(7) to git(1)Christian Couder2008-06-061-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>
* Documentation: rename gitlink macro to linkgitDan McGee2008-01-061-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>
* War on whitespaceJunio C Hamano2007-06-071-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>
* Documentation: sync git.txt command list and manual page titleJunio C Hamano2007-01-181-1/+1
| | | | | | | Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Update the documentation for git-merge-baseFredrik Kuivinen2006-05-151-4/+14
| | | | | Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Remove the version tags from the manpagesJunio C Hamano2005-10-101-1/+0
| | | | | Signed-off-by: Christian Meder <chris@absolutegiganten.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] Documentation: Update all files to use the new gitlink: macroSergey Vlasov2005-09-201-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>
* [PATCH 1/4] split core-git.txt and updateDavid Greaves2005-05-101-0/+34
Split the core-git.txt file Formatting fix to the diff-format.txt Signed-off-by: David Greaves <david@dgreaves.com>
View Lorry Controller Status