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

docs: fix formatting and grammar

2017-06-02T05:10:57Z

When compiling the documentation, asciidoc thinks a backtick surrounded by whitespace shouldn't be interpreted as marking the start or end of a literal. In most cases, that's useful behaviour, but in the git-pull documentation it means asciidoc is failing to correctly detect which text should be monospaced and which shouldn't. To avoid this, remove the extraneous spaces from the text to be monospaced. It would also be possible to fix the formatting by switching to asciidoc's ++ monospace format markers and still have the space characters included in the monospace text, but the spaces aren't necessary and not having them keeps the markup simpler. Also include a minor grammar fix suggested by Jeff while we're changing these lines. Signed-off-by: Adam Dinwoodie Helped-by: Jeff King Signed-off-by: Junio C Hamano

doc: git-pull.txt use US spelling, fix minor typo

2017-05-01T02:03:08Z

Signed-off-by: René Genz Signed-off-by: Junio C Hamano

Merge branch 'mm/push-social-engineering-attack-doc'

2017-01-10T23:24:24Z

Doc update on fetching and pushing. * mm/push-social-engineering-attack-doc: doc: mention transfer data leaks in more places

doc: mention transfer data leaks in more places

2016-11-14T19:23:07Z

The "SECURITY" section of the gitnamespaces(7) man page described two ways for a client to steal data from a server that wasn't intended to be shared. Similar attacks can be performed by a server on a client, so adapt the section to cover both directions and add it to the git-fetch(1), git-pull(1), and git-push(1) man pages. Also add references to this section from the documentation of server configuration options that attempt to control data leakage but may not be fully effective. Signed-off-by: Matt McCutchen Signed-off-by: Junio C Hamano

pull --rebase: add --[no-]autostash flag

2016-03-21T20:30:36Z

If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line. Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the --[no-]autostash option, it's just a matter of passing the option to underlying "git rebase" when "git pull --rebase" is called. Helped-by: Matthieu Moy Helped-by: Junio C Hamano Helped-by: Paul Tan Helped-by: Eric Sunshine Signed-off-by: Mehul Jain Signed-off-by: Junio C Hamano

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