git/Documentation/git-pull.txt, branch v2.8.2

pull: allow interactive rebase with --rebase=interactive

2016-01-13T20:59:15Z

A couple of years ago, I found the need to collaborate on topic branches that were rebased all the time, and I really needed to see what I was rebasing when pulling, so I introduced an interactively-rebasing pull. The way builtin pull works, this change also supports the value 'interactive' for the 'branch..rebase' config variable, which is a neat thing because users can now configure given branches for interactively-rebasing pulls without having to type out the complete `--rebase=interactive` option every time they pull. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

pull: handle git-fetch's options as well

2015-06-02T20:36:22Z

While parsing the command-line arguments, git-pull stops parsing at the first unrecognized option, assuming that any subsequent options are for git-fetch, and can thus be kept in the shell's positional parameters list, so that it can be passed to git-fetch via the expansion of "$@". However, certain functions in git-pull assume that the positional parameters do not contain any options: * error_on_no_merge_candidates() uses the number of positional parameters to determine which error message to print out, and will thus print the wrong message if git-fetch's options are passed in as well. * the call to get_remote_merge_branch() assumes that the positional parameters only contains the optional repo and refspecs, and will thus silently fail if git-fetch's options are passed in as well. * --dry-run is a valid git-fetch option, but if provided after any git-fetch options, it is not recognized by git-pull and thus git-pull will continue to run the merge or rebase. Fix these bugs by teaching git-pull to parse git-fetch's options as well. Add tests to prevent regressions. This removes the limitation where git-fetch's options have to come after git-merge's and git-rebase's options on the command line. Update the documentation to reflect this. Signed-off-by: Paul Tan Signed-off-by: Junio C Hamano

Merge branch 'ss/pull-rebase-preserve'

2015-03-28T16:37:52Z

* ss/pull-rebase-preserve: docs: clarify "preserve" option wording for git-pull

docs: clarify "preserve" option wording for git-pull

2015-03-26T20:19:26Z

The "also" sounds as if "preserve" does a rebase as an additional step that "true" would not do, but that is not the case. Clarify this by omitting "also", and rewording the sentence a bit. Signed-off-by: Sebastian Schuberth Signed-off-by: Junio C Hamano

*config.txt: stick to camelCase naming convention

2015-03-14T05:13:46Z

This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

Merge branch 'jc/maint-pull-docfix'

2014-01-27T18:44:00Z

* jc/maint-pull-docfix: Documentation: "git pull" does not have the "-m" option Documentation: exclude irrelevant options from "git pull"

Merge branch 'jc/maint-pull-docfix-for-409b8d82' into jc/maint-pull-docfix

2014-01-14T18:47:09Z

* jc/maint-pull-docfix-for-409b8d82: Documentation: exclude irrelevant options from "git pull"

Documentation: exclude irrelevant options from "git pull"

2014-01-14T18:46:17Z

10eb64f5 (git pull manpage: don't include -n from fetch-options.txt, 2008-01-25) introduced a way to exclude some parts of included source when building git-pull documentation, and later 409b8d82 (Documentation/git-pull: put verbosity options before merge/fetch ones, 2010-02-24) attempted to use the mechanism to exclude some parts of merge-options.txt when used from git-pull.txt. However, the latter did not have an intended effect, because the macro "git-pull" used to decide if the source is included in git-pull documentation were defined a bit too late. Define the macro before it is used to fix this. Signed-off-by: Junio C Hamano

doc/pull: clarify the illustrations

2013-10-31T20:45:29Z

The second illustration that shows the history after "git pull" spelled the remote-tracking branch with "remotes/" prefix, which is not necessary. Drop it. To match the assumption that a remote-tracking branch is used to keep track of the advancement of the master at the origin, update the first illustration that shows the history before "git pull" to show the distinction between the master currently at origin and the stale origin/master remote-tracking branch. Noticed-by: Felipe Contreras Helped-by: Max Horn Signed-off-by: Junio C Hamano

pull: allow pull to preserve merges when rebasing

2013-09-04T19:45:48Z

If a user is working on master, and has merged in their feature branch, but now has to "git pull" because master moved, with pull.rebase their feature branch will be flattened into master. This is because "git pull" currently does not know about rebase's preserve merges flag, which would avoid this behavior, as it would instead replay just the merge commit of the feature branch onto the new master, and not replay each individual commit in the feature branch. Add a --rebase=preserve option, which will pass along --preserve-merges to rebase. Also add 'preserve' to the allowed values for the pull.rebase config setting. Signed-off-by: Stephen Haberman Signed-off-by: Junio C Hamano