summaryrefslogtreecommitdiff
path: root/Documentation/merge-options.txt
AgeCommit message (Collapse)AuthorFilesLines
2014-03-31Documentation: fix misuses of "nor"Libravatar Justin Lebar1-8/+7
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-27Merge branch 'jc/maint-pull-docfix'Libravatar Junio C Hamano1-3/+6
* jc/maint-pull-docfix: Documentation: "git pull" does not have the "-m" option Documentation: exclude irrelevant options from "git pull"
2014-01-14Documentation: "git pull" does not have the "-m" optionLibravatar Junio C Hamano1-3/+6
Even though "--[no-]edit" can be used with "git pull", the explanation of the interaction between this option and the "-m" option does not make sense within the context of "git pull". Use the conditional inclusion mechanism to remove this part from "git pull" documentation, while keeping it for "git merge". Reported-by: Ivan Zakharyaschev Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02Merge branch 'rh/merge-options-doc-fix'Libravatar Junio C Hamano1-1/+2
* rh/merge-options-doc-fix: Documentation/merge-options.txt: restore `-e` option
2013-05-16Documentation/merge-options.txt: restore `-e` optionLibravatar Richard Hansen1-1/+2
It looks like commit f8246281af9adb0fdddbcc90d2e19cb5cd5217e5 unintentionally removed the documentation for the `-e` option. Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'sg/gpg-sig'Libravatar Junio C Hamano1-0/+5
Teach "merge/pull" to optionally verify and reject commits that are not signed properly. * sg/gpg-sig: pretty printing: extend %G? to include 'N' and 'U' merge/pull Check for untrusted good GPG signatures merge/pull: verify GPG signatures of commits being merged commit.c/GPG signature verification: Also look at the first GPG status line Move commit GPG signature verification to commit.c
2013-03-31merge/pull Check for untrusted good GPG signaturesLibravatar Sebastian Götte1-2/+2
When --verify-signatures is specified, abort the merge in case a good GPG signature from an untrusted key is encountered. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31merge/pull: verify GPG signatures of commits being mergedLibravatar Sebastian Götte1-0/+5
When --verify-signatures is specified on the command-line of git-merge or git-pull, check whether the commits being merged have good gpg signatures and abort the merge in case they do not. This allows e.g. auto-deployment from untrusted repo hosts. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21Documentation: merging a tag is a special caseLibravatar Junio C Hamano1-1/+2
When asking Git to merge a tag (such as a signed tag or annotated tag), it will always create a merge commit even if fast-forward was possible. It's like having --no-ff present on the command line. It's a difference from the default behavior described in git-merge.txt. It should be documented as an exception of "FAST-FORWARD MERGE" section and "--ff" option description. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-26Merge branch 'jc/doc-merge-options'Libravatar Junio C Hamano1-11/+11
* jc/doc-merge-options: Documentation/merge-options.txt: group "ff" related options together
2012-02-22Documentation/merge-options.txt: group "ff" related options togetherLibravatar Junio C Hamano1-11/+11
The --ff-only option was not described next to --ff and --no-ff options in "git merge" documentation, even though these three are logically together, describing how to choose one of three possibilities. Also the description for '--ff' and '--no-ff' discussed what '--ff' means, and mentioned '--no-ff' as if it were a side-note to '--ff'. Make them into three top-level entries and list them together. This way, it would be more clear that the user can choose one from these three. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-23merge: use editor by default in interactive sessionsLibravatar Junio C Hamano1-3/+13
Traditionally, a cleanly resolved merge was committed by "git merge" using the auto-generated merge commit log message without invoking the editor. After 5 years of use in the field, it turns out that people perform too many unjustified merges of the upstream history into their topic branches. These merges are not just useless, but they are often not explained well, and making the end result unreadable when it gets time for merging their history back to their upstream. Earlier we added the "--edit" option to the command, so that people can edit the log message to explain and justify their merge commits. Let's take it one step further and spawn the editor by default when we are in an interactive session (i.e. the standard input and the standard output are pointing at the same tty device). There may be existing scripts that leave the standard input and the standard output of the "git merge" connected to whatever environment the scripts were started, and such invocation might trigger the above "interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable can be set to "no" at the beginning of such scripts to use the historical behaviour while the script runs. Note that this backward compatibility is meant only for scripts, and we deliberately do *not* support "merge.edit = yes/no/auto" configuration option to allow people to keep the historical behaviour. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05Documentation: fix formatting error in merge-options.txtLibravatar Jack Nagel1-1/+0
The first paragraph inside of a list item does not need a preceding line consisting of a single '+', and in fact this causes the text to be misrendered. Fix it. Signed-off-by: Jack Nagel <jacknagel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12Teach merge the '[-e|--edit]' optionLibravatar Jay Soffian1-0/+6
Implemented internally instead of as "git merge --no-commit && git commit" so that "merge --edit" is otherwise consistent (hooks, etc) with "merge". Note: the edit message does not include the status information that one gets with "commit --status" and it is cleaned up after editing like one gets with "commit --cleanup=default". A later patch could add the status information if desired. Note: previously we were not calling stripspace() after running the prepare-commit-msg hook. Now we are, stripping comments and leading/trailing whitespace lines if --edit is given, otherwise only stripping leading/trailing whitespace lines if not given --edit. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21merge: enable progress reporting for rename detectionLibravatar Jeff King1-1/+9
The user can enable or disable it explicitly with the new --progress, but it defaults to checking isatty(2). This works only with merge-recursive and subtree. In theory we could pass a progress flag to other strategies, but none of them support progress at this point, so let's wait until they grow such a feature before worrying about propagating it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-09merge: Make '--log' an integer option for number of shortlog entriesLibravatar Ramkumar Ramachandra1-3/+3
Change the command-line '--log' option from a boolean option to an integer option, and parse the optional integer provided on the command-line into the 'shortlog_len' variable. Also update the documentation accordingly. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reported-by: Yaroslav Halchenko <debian@onerussian.com> Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-13Merge branch 'maint'Libravatar Junio C Hamano1-5/+5
* maint: Documentation/config.txt: default gc.aggressiveWindow is 250, not 10 Docs: Add -X option to git-merge's synopsis. Conflicts: Documentation/merge-options.txt
2010-04-12Docs: Add -X option to git-merge's synopsis.Libravatar Marc Branchaud1-5/+5
Also move -X's description next to -s's in merge-options.txt. This makes it easier to learn how to specify merge strategy options. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24Documentation/git-pull: put verbosity options before merge/fetch onesLibravatar Tay Ray Chuan1-0/+2
After 3f7a9b5 (Documentation/git-pull.txt: Add subtitles above included option files, Thu Oct 22 2009), the -q/-v options were mentioned only for the merge options section, giving the impression that git-fetch did not take those arguments. Follow 90e4311 (git-pull: do not mention --quiet and --verbose twice, Mon Sep 7 2009) and hide -q/-v for merge options, while mentioning -q/-v before the merge- and fetch-specific options. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'ap/merge-backend-opts'Libravatar Junio C Hamano1-0/+5
* ap/merge-backend-opts: Document that merge strategies can now take their own options Extend merge-subtree tests to test -Xsubtree=dir. Make "subtree" part more orthogonal to the rest of merge-recursive. pull: Fix parsing of -X<option> Teach git-pull to pass -X<option> to git-merge git merge -X<option> git-merge-file --ours, --theirs Conflicts: git-compat-util.h
2010-01-17Document that merge strategies can now take their own optionsLibravatar Junio C Hamano1-0/+5
Also document the recently added -Xtheirs, -Xours and -Xsubtree[=path] options to the merge-recursive strategy. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-2/+2
The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
2009-11-10Merge branch 'bg/merge-ff-only'Libravatar Junio C Hamano1-0/+5
* bg/merge-ff-only: Teach 'git merge' and 'git pull' the option --ff-only
2009-10-30Teach 'git merge' and 'git pull' the option --ff-onlyLibravatar Björn Gustavsson1-0/+5
For convenience in scripts and aliases, add the option --ff-only to only allow fast-forwards (and up-to-date, despite the name). Disallow combining --ff-only and --no-ff, since they flatly contradict each other. Allow all other options to be combined with --ff-only (i.e. do not add any code to handle them specially), including the following options: * --strategy (one or more): As long as the chosen merge strategy results in up-to-date or fast-forward, the command will succeed. * --squash: I cannot imagine why anyone would want to squash commits only if fast-forward is possible, but I also see no reason why it should not be allowed. * --message: The message will always be ignored, but I see no need to explicitly disallow providing a redundant message. Acknowledgements: I did look at Yuval Kogman's earlier patch (107768 in gmane), mainly as shortcut to find my way in the code, but I did not copy anything directly. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-22Documentation/merge-options.txt: order options in alphabetical groupsLibravatar Jari Aalto1-43/+45
Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-25merge-options.txt: Clarify merge --squashLibravatar Michael J Gruber1-1/+2
With the --squash option, merge sets up the index just like for a real merge, but without the merge info (stages). Say so. 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-1/+1
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-11-14Teach/Fix pull/fetch -q/-v optionsLibravatar Tuncer Ayaz1-0/+8
Implement git-pull --quiet and git-pull --verbose by adding the options to git-pull and fixing verbosity handling in git-fetch. 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-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-3/+6
The OPTIONS section of a documentation file contains a list of the options a git command accepts. Currently there are several variants to describe the case that different options (almost) do the same in the OPTIONS section. Some are: -f, --foo:: -f|--foo:: -f | --foo:: But AsciiDoc has the special form: -f:: --foo:: This patch applies this form to the documentation of the whole git suite, and removes useless em-dash prevention, so \--foo becomes --foo. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12merge, pull: add '--(no-)log' command line optionLibravatar SZEDER Gábor1-0/+9
These are the command line option equivalents of the 'merge.log' config variable. The patch also updates documentation and bash completion accordingly, and adds a test. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12add 'merge.stat' config variableLibravatar SZEDER Gábor1-1/+1
This variable has the same effect, as 'merge.diffstat'. Also mention it in the documentation. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12merge, pull: introduce '--(no-)stat' optionLibravatar SZEDER Gábor1-2/+6
This option has the same effect as '--(no-)summary' (i.e. whether to show a diffsat at the end of the merge or not), and it is consistent with the '--stat' option of other git commands. Documentation, tests, and bash completion are updaed accordingly, and the old --summary option is marked as being deprected. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23git-merge: add --ff and --no-ff optionsLibravatar Lars Hjemli1-0/+9
These new options can be used to control the policy for fast-forward merges: --ff allows it (this is the default) while --no-ff will create a merge commit. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23git-merge: add support for --commit and --no-squashLibravatar Lars Hjemli1-0/+8
These options can be used to override --no-commit and --squash, which is needed since --no-commit and --squash now can be specified as default merge options in $GIT_DIR/config. The change also introduces slightly different behavior for --no-commit: when specified, it explicitly overrides --squash. Earlier, 'git merge --squash --no-commit' would result in a squashed merge (i.e. no $GIT_DIR/MERGE_HEAD was created) but with this patch the command will behave as if --squash hadn't been specified. Signed-off-by: Lars Hjemli <hjemli@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-05-24Add a configuration option to control diffstat after mergeLibravatar Alex Riesen1-0/+4
The diffstat can be controlled either with command-line options (--summary|--no-summary) or with merge.diffstat. The default is left as it was: diffstat is active by default. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24git-merge --squashLibravatar Junio C Hamano1-0/+8
Some people tend to do many little commits on a topic branch, recording all the trials and errors, and when the topic is reasonably cooked well, would want to record the net effect of the series as one commit on top of the mainline, removing the cruft from the history. The topic is then abandoned or forked off again from that point at the mainline. The barebone porcelainish that comes with core git tools does not officially support such operation, but you can fake it by using "git pull --no-merge" when such a topic branch is not a strict superset of the mainline, like this: git checkout mainline git pull --no-commit . that-topic-branch : fix conflicts if any rm -f .git/MERGE_HEAD git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged This however does not work when the topic branch is a fast forward of the mainline, because normal "git pull" will never create a merge commit in such a case, and there is nothing special --no-commit could do to begin with. This patch introduces a new option, --squash, to support such a workflow officially in both fast-forward case and true merge case. The user-level operation would be the same in both cases: git checkout mainline git pull --squash . that-topic-branch : fix conflicts if any -- naturally, there would be : no conflict if fast forward. git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged When the current branch is already up-to-date with respect to the other branch, there truly is nothing to do, so the new option does not have any effect. This was brought up in #git IRC channel recently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-08Documentation: recursive is the default strategy these days.Libravatar Junio C Hamano1-1/+1
We still said resolve was the default in handful places. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-06Refactored merge options into separate merge-options.txt.Libravatar Jon Loeliger1-0/+16
Refactored fetch options into separate fetch-options.txt. Made git-merge use merge-options. Made git-fetch use fetch-options. Made git-pull use merge-options and fetch-options. Added --help option to git-pull and git-format-patch scripts. Rewrote Documentation/Makefile to dynamically determine include dependencies. Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <junkio@cox.net>