summaryrefslogtreecommitdiff
path: root/Documentation/git-pull.txt
AgeCommit message (Collapse)AuthorFilesLines
2020-04-05pull doc: correct outdated description of an exampleLibravatar Philippe Blain1-3/+3
Since f269048754 (fetch: opportunistically update tracking refs, 2013-05-11), the underlying `git fetch` in `git pull <remote> <branch>` updates the configured remote-tracking branch for <branch>. However, an example in the 'Examples' section of the `git pull` documentation still states that this is not the case. Correct the description of this example. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-05doc: typo: s/can not/cannot/ and s/is does/does/Libravatar Mark Rushakoff1-1/+1
"Can not" suggests one has the option to not do something, whereas "cannot" more strongly suggests something is disallowed or impossible. Noticed "can not", mistakenly used instead of "cannot" in git help glossary, then ran git grep 'can not' and found many other instances. Only files in the Documentation folder were modified. 'Can not' also occurs in some source code comments and some test assertion messages, and there is an error message and translation "can not move directory into itself" which I may fix and submit separately from the documentation change. Also noticed and fixed "is does" in git help fetch, but there are no other occurrences of that typo according to git grep. Signed-off-by: Mark Rushakoff <mark.rushakoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28docs: say that `--rebase=preserve` is deprecatedLibravatar Johannes Schindelin1-2/+3
As of Git v2.22.0, the `--preserve-merges` backend of `git rebase` will be officially deprecated in favor of the `--rebase-merges` backend. Consequently, `git pull --rebase=preserve` will also be deprected. State this explicitly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-25Use proper syntax for replaceables in command docsLibravatar Robert P. J. Day1-1/+1
The standard for command documentation synopses appears to be: [...] means optional <...> means replaceable [<...>] means both optional and replaceable So fix a number of doc pages that use incorrect variations of the above. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26pull: accept --rebase=merges to recreate the branch topologyLibravatar Johannes Schindelin1-1/+5
Similar to the `preserve` mode simply passing the `--preserve-merges` option to the `rebase` command, the `merges` mode simply passes the `--rebase-merges` option. This will allow users to conveniently rebase non-trivial commit topologies when pulling new commits, without flattening them. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13Merge branch 'sb/pull-rebase-submodule'Libravatar Junio C Hamano1-6/+6
"git pull --rebase --recurse-submodules" learns to rebase the branch in the submodules to an updated base. * sb/pull-rebase-submodule: builtin/fetch cleanup: always set default value for submodule recursing pull: optionally rebase submodules (remote submodule changes only) builtin/fetch: parse recurse-submodules-default at default options parsing builtin/fetch: factor submodule recurse parsing out to submodule config
2017-06-23pull: optionally rebase submodules (remote submodule changes only)Libravatar Stefan Beller1-6/+6
Teach pull to optionally update submodules when '--recurse-submodules' is provided. This will teach pull to run 'submodule update --rebase' when the '--recurse-submodules' and '--rebase' flags are given under specific circumstances. On a rebase workflow: ===================== 1. Both sides change the submodule ------------------------------ Let's assume the following history in a submodule: H---I---J---K---L local branch \ M---N---O---P remote branch and the following in the superproject (recorded submodule in parens): A(H)---B(I)---F(K)---G(L) local branch \ C(N)---D(N)---E(P) remote branch In an ideal world this would rebase the submodule and rewrite the submodule pointers that the superproject points at such that the superproject looks like A(H)---B(I) F(K')---G(L') rebased branch \ / C(N)---D(N)---E(P) remote branch and the submodule as: J---K---L (old dangeling tip) / H---I J'---K'---L' rebased branch \ / M---N---O---P remote branch And if a conflict arises in the submodule the superproject rebase would stop at that commit at which the submodule conflict occurs. Currently a "pull --rebase" in the superproject produces a merge conflict as the submodule pointer changes are conflicting and cannot be resolved. 2. Local submodule changes only ----------------------- Assuming histories as above, except that the remote branch would not contain submodule changes, then a result as A(H)---B(I) F(K)---G(L) rebased branch \ / C(I)---D(I)---E(I) remote branch is desire-able. This is what currently happens in rebase. If the recursive flag is given, the ideal git would produce a superproject as: A(H)---B(I) F(K')---G(L') rebased branch (incl. sub rebase!) \ / C(I)---D(I)---E(I) remote branch and the submodule as: J---K---L (old dangeling tip) / H---I J'---K'---L' locally rebased branch \ / M---N---O---P advanced branch This patch doesn't address this issue, however a test is added that this fails up front. 3. Remote submodule changes only ---------------------- Assuming histories as in (1) except that the local superproject branch would not have touched the submodule the rebase already works out in the superproject with no conflicts: A(H)---B(I) F(P)---G(P) rebased branch (no sub changes) \ / C(N)---D(N)---E(P) remote branch The recurse flag as presented in this patch would additionally update the submodule as: H---I J'---K'---L' rebased branch \ / M---N---O---P remote branch As neither J, K, L nor J', K', L' are referred to from the superproject, no rewriting of the superproject commits is required. Conclusion for 'pull --rebase --recursive' ----------------------------------------- If there are no local superproject changes it is sufficient to call "submodule update --rebase" as this produces the desired results. In case of conflicts, the behavior is the same as in 'submodule update --recursive' which is assumed to be sane. This patch implements (3) only. On a merge workflow: ==================== We'll start off with the same underlying DAG as in (1) in the rebase workflow. So in an ideal world a 'pull --merge --recursive' would produce this: H---I---J---K---L----X \ / M---N---O---P with X as the new merge-commit in the submodule and the superproject as: A(H)---B(I)---F(K)---G(L)---Y(X) \ / C(N)---D(N)---E(P) However modifying the submodules on the fly is not supported in git-merge such that Y(X) is not easy to produce in a single patch. In fact git-merge doesn't know about submodules at all. However when at least one side does not contain commits touching the submodule at all, then we do not need to perform the merge for the submodule but a fast-forward can be done via checking out either L or P in the submodule. This strategy is implemented in 68d03e4a6e (Implement automatic fast-forward merge for submodules, 2010-07-07) already, so to align with the rebase behavior we need to also update the worktree of the submodule. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18stash: update documentation to use 'stash entry'Libravatar Liam Beguin1-1/+1
Most of the time, a 'stash entry' is called a 'stash'. Lets try to make this more consistent and use 'stash entry' instead. Signed-off-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02docs: fix formatting and grammarLibravatar Adam Dinwoodie1-3/+3
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 <adam@dinwoodie.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-01doc: git-pull.txt use US spelling, fix minor typoLibravatar René Genz1-2/+3
Signed-off-by: René Genz <liebundartig@freenet.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10Merge branch 'mm/push-social-engineering-attack-doc'Libravatar Junio C Hamano1-0/+2
Doc update on fetching and pushing. * mm/push-social-engineering-attack-doc: doc: mention transfer data leaks in more places
2016-11-14doc: mention transfer data leaks in more placesLibravatar Matt McCutchen1-0/+2
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 <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-21pull --rebase: add --[no-]autostash flagLibravatar Mehul Jain1-0/+9
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 <Matthieu.Moy@grenoble-inp.fr> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Paul Tan <pyokagan@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13pull: allow interactive rebase with --rebase=interactiveLibravatar Johannes Schindelin1-1/+3
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.<name>.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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-02pull: handle git-fetch's options as wellLibravatar Paul Tan1-3/+0
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 <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-28Merge branch 'ss/pull-rebase-preserve'Libravatar Junio C Hamano1-3/+2
* ss/pull-rebase-preserve: docs: clarify "preserve" option wording for git-pull
2015-03-26docs: clarify "preserve" option wording for git-pullLibravatar Sebastian Schuberth1-3/+2
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 <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-1/+1
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 <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-27Merge branch 'jc/maint-pull-docfix'Libravatar Junio C Hamano1-2/+2
* jc/maint-pull-docfix: Documentation: "git pull" does not have the "-m" option Documentation: exclude irrelevant options from "git pull"
2014-01-14Merge branch 'jc/maint-pull-docfix-for-409b8d82' into jc/maint-pull-docfixLibravatar Junio C Hamano1-2/+2
* jc/maint-pull-docfix-for-409b8d82: Documentation: exclude irrelevant options from "git pull"
2014-01-14Documentation: exclude irrelevant options from "git pull"Libravatar Junio C Hamano1-2/+2
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 <gitster@pobox.com>
2013-10-31doc/pull: clarify the illustrationsLibravatar Junio C Hamano1-1/+3
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 <felipe.contreras@gmail.com> Helped-by: Max Horn <max@quendi.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04pull: allow pull to preserve merges when rebasingLibravatar Stephen Haberman1-6/+12
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 <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-08pull: change the description to "integrate" changesLibravatar John Keeping1-1/+1
Since git-pull learned the --rebase option it has not just been about merging changes from a remote repository (where "merge" is in the sense of "git merge"). Change the description to use "integrate" instead of "merge" in order to reflect this. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27Merge branch 'maint-1.8.1' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.8.1: merge-tree: fix typo in merge-tree.c::unresolved git-commit doc: describe use of multiple `-m` options git-pull doc: fix grammo ("conflicts" is plural)
2013-03-27git-pull doc: fix grammo ("conflicts" is plural)Libravatar Mihai Capotă1-1/+1
Signed-off-by: Mihai Capotă <mihai@mihaic.ro> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-4/+4
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-17man: git pull -r is a short for --rebaseLibravatar Miklos Vajna1-0/+1
Letting the "--rebase" option squat on the short-and-sweet single letter option "-r" was an unintended accident and was not even documented, but the short option seems to be already used in the wild. Let's document it so that other options that begin with "r" would not be tempted to steal it. Signed-off-by: Miklos Vajna <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-1/+1
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'ab/pull-rebase-config'Libravatar Junio C Hamano1-1/+1
* ab/pull-rebase-config: pull: introduce a pull.rebase option to enable --rebase
2011-11-07pull: introduce a pull.rebase option to enable --rebaseLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Currently we either need to set branch.<name>.rebase for existing branches if we'd like "git pull" to mean "git pull --rebase", or have the forethought of setting "branch.autosetuprebase" before we create the branch. Introduce a "pull.rebase" option to globally configure "git pull" to mean "git pull --rebase" for any branch. This option will be considered at a lower priority than branch.<name>.rebase, i.e. we could set pull.rebase=true and branch.<name>.rebase=false and the latter configuration option would win. Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com> Reviewed-by: Fernando Vezzosi <buccia@repnz.net> Reviewed-by: Eric Herman <eric@freesa.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsLibravatar Martin von Zweigbergk1-0/+1
The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-04Merge branch 'jl/submodule-fetch-on-demand'Libravatar Junio C Hamano1-1/+10
* jl/submodule-fetch-on-demand: fetch/pull: Describe --recurse-submodule restrictions in the BUGS section submodule update: Don't fetch when the submodule commit is already present fetch/pull: Don't recurse into a submodule when commits are already present Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option config: teach the fetch.recurseSubmodules option the 'on-demand' value fetch/pull: Add the 'on-demand' value to the --recurse-submodules option fetch/pull: recurse into submodules when necessary Conflicts: builtin/fetch.c submodule.c
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-12/+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.
2011-03-09fetch/pull: Describe --recurse-submodule restrictions in the BUGS sectionLibravatar Jens Lehmann1-0/+9
Using the --recurse-submodules option with fetch and pull might not always fetch all the submodule commits the user expects, as this will only work when the submodule is already checked out. Document that and warn that this is expected to change in the future. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09fetch/pull: Add the 'on-demand' value to the --recurse-submodules optionLibravatar Jens Lehmann1-1/+1
Until now the --recurse-submodules option could only be used to either fetch all populated submodules recursively or to disable recursion completely. As fetch and pull now by default just fetch those submodules for which new commits have been fetched in the superproject, a command line option to enforce that behavior is needed to be able to override configuration settings. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-07pull: Document the "--[no-]recurse-submodules" optionsLibravatar Jens Lehmann1-0/+9
In commits be254a0ea9 and 7dce19d374 the handling of the new fetch options "--[no-]recurse-submodules" had been added to git-pull.sh. But they were not documented as the pull options they now are, so let's fix that. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-12Merge branch 'ja/maint-pull-rebase-doc'Libravatar Junio C Hamano1-2/+3
* ja/maint-pull-rebase-doc: git-pull.txt: Mention branch.autosetuprebase
2010-12-03Merge branch 'maint' to sync with Git 1.7.3.3Libravatar Junio C Hamano1-2/+2
* maint: Git 1.7.3.3 CodingGuidelines: mention whitespace preferences for shell scripts Documentation: do not misinterpret pull refspec as bold text Conflicts: Documentation/git-pull.txt RelNotes
2010-12-03Documentation: do not misinterpret pull refspec as bold textLibravatar Jonathan Nieder1-2/+2
Use the {asterisk} entity to avoid mistreating the asterisks in "(e.g., refs/heads/*:refs/remotes/origin/*)" as delimiters for bold text. From a quick search with 'git grep -e "\*.*\*"', this seems to be the last example of this particular formatting problem. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-03git-pull.txt: Mention branch.autosetuprebaseLibravatar Jari Aalto1-2/+3
In "Options related to merging" mention also related option branch.autosetuprebase in git-config(1). Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24Merge branch 'mm/phrase-remote-tracking'Libravatar Junio C Hamano1-4/+4
* mm/phrase-remote-tracking: git-branch.txt: mention --set-upstream as a way to change upstream configuration user-manual: remote-tracking can be checked out, with detached HEAD user-manual.txt: explain better the remote(-tracking) branch terms Change incorrect "remote branch" to "remote tracking branch" in C code Change incorrect uses of "remote branch" meaning "remote-tracking" Change "tracking branch" to "remote-tracking branch" everyday.txt: change "tracking branch" to "remote-tracking branch" Change remote tracking to remote-tracking in non-trivial places Replace "remote tracking" with "remote-tracking" Better "Changed but not updated" message in git-status
2010-11-17Documentation/git-pull: clarify configurationLibravatar Martin von Zweigbergk1-6/+8
The sentence about 'branch.<name>.rebase' refers to the first sentence in the paragraph and not to the sentence about avoiding rebasing non-local changes. Clarify this. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Change "tracking branch" to "remote-tracking branch"Libravatar Matthieu Moy1-3/+3
One more step towards consistancy. We change the documentation and the C code in a single patch, since the only instances in the C code are in comment and usage strings. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Replace "remote tracking" with "remote-tracking"Libravatar Matthieu Moy1-1/+1
"remote-tracking" branch makes it explicit that the branch is "tracking a remote", as opposed to "remote, and tracking something". See discussion in e.g. http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com for more details. This patch is a straightforward application of perl -pi -e 's/remote tracking branch/remote-tracking branch/' except in the RelNotes directory. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-02Documentation: flesh out “git pull” descriptionLibravatar Jonathan Nieder1-11/+54
The current description in the pull man page does not say much more than that “git pull” is fetch + merge. Though that is all a person needs to know in the end, it would be useful to summarize a bit about what those commands do for new readers. Most of this description is taken from the “git merge” docs. Now that we explain how to back out of a failed merge (reset --merge), we can tone down the warning against that a bit. Except, as Thomas noticed, there’s a risk with that because people might read this version of the manpage online and then conclude that it is safe to try a merge with uncommitted changes, only to find that their “git reset” doesn't support --merge yet. Or worse, verify that their git-reset has --merge by a quick test (1b5b465 is in 1.6.2) but then find that it does not help with backing out of a merge (e11d7b5 is only in 1.7.0!). So keep the warning. With clarifications from Ævar, Thomas, and Junio. Noticed-by: Geoff Russell <geoffrey.russell@gmail.com> Cc: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24fetch and pull: learn --progressLibravatar Tay Ray Chuan1-1/+3
Note that in the documentation for git-pull, documentation for the --progress option is displayed under the "Options related to fetching" subtitle via fetch-options.txt. Also, update the documentation of the -q/--quiet option for git-pull to mention its effect on progress reporting during fetching. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> 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/+8
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-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-6/+6
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.
2010-01-09Documentation: warn prominently against merging with dirty treesLibravatar Thomas Rast1-0/+4
We do this for both git-merge and git-pull, so as to hopefully alert (over)users of git-pull to the issue. Signed-off-by: Thomas Rast <trast@student.ethz.ch>