1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-29 21:37:53 +01:00
Commit graph

88 commits

Author SHA1 Message Date
Johannes Schindelin
7401ab92f8 docs: say that --rebase=preserve is deprecated
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>
2019-05-28 13:22:34 -07:00
Robert P. J. Day
de613050ef Use proper syntax for replaceables in command docs
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-05-25 17:16:47 +09:00
Johannes Schindelin
1131ec9818 pull: accept --rebase=merges to recreate the branch topology
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>
2018-04-26 12:28:43 +09:00
Junio C Hamano
c9c63ee558 Merge branch 'sb/pull-rebase-submodule'
"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-07-13 16:14:54 -07:00
Stefan Beller
a6d7eb2c7a pull: optionally rebase submodules (remote submodule changes only)
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-23 15:36:53 -07:00
Liam Beguin
e01db917d8 stash: update documentation to use 'stash entry'
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-18 22:16:36 -07:00
Adam Dinwoodie
0c79cee697 docs: fix formatting and grammar
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-06-02 14:10:57 +09:00
René Genz
d395745d81 doc: git-pull.txt use US spelling, fix minor typo
Signed-off-by: René Genz <liebundartig@freenet.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-01 11:03:08 +09:00
Junio C Hamano
5f52e70879 Merge branch 'mm/push-social-engineering-attack-doc'
Doc update on fetching and pushing.

* mm/push-social-engineering-attack-doc:
  doc: mention transfer data leaks in more places
2017-01-10 15:24:24 -08:00
Matt McCutchen
235ec24352 doc: mention transfer data leaks in more places
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-11-14 11:23:07 -08:00
Mehul Jain
f66398eb57 pull --rebase: add --[no-]autostash flag
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-03-21 13:30:36 -07:00
Johannes Schindelin
f5eb87b98d pull: allow interactive rebase with --rebase=interactive
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>
2016-01-13 12:59:15 -08:00
Paul Tan
eb2a8d9ed3 pull: handle git-fetch's options as well
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-06-02 13:36:22 -07:00
Junio C Hamano
3a183520b2 Merge branch 'ss/pull-rebase-preserve'
* ss/pull-rebase-preserve:
  docs: clarify "preserve" option wording for git-pull
2015-03-28 09:37:52 -07:00
Sebastian Schuberth
129260cbd4 docs: clarify "preserve" option wording for git-pull
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-26 13:19:26 -07:00
Nguyễn Thái Ngọc Duy
da0005b885 *config.txt: stick to camelCase naming convention
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>
2015-03-13 22:13:46 -07:00
Junio C Hamano
6d73dba8f6 Merge branch 'jc/maint-pull-docfix'
* jc/maint-pull-docfix:
  Documentation: "git pull" does not have the "-m" option
  Documentation: exclude irrelevant options from "git pull"
2014-01-27 10:44:00 -08:00
Junio C Hamano
8be1d04a7e Merge branch 'jc/maint-pull-docfix-for-409b8d82' into jc/maint-pull-docfix
* jc/maint-pull-docfix-for-409b8d82:
  Documentation: exclude irrelevant options from "git pull"
2014-01-14 10:47:09 -08:00
Junio C Hamano
d51a47552a Documentation: exclude irrelevant options from "git pull"
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>
2014-01-14 10:46:17 -08:00
Junio C Hamano
5a3fd6afd4 doc/pull: clarify the illustrations
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-10-31 13:45:29 -07:00
Stephen Haberman
66713ef3b0 pull: allow pull to preserve merges when rebasing
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-09-04 12:45:48 -07:00
John Keeping
153d7265ef pull: change the description to "integrate" changes
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-07-08 12:44:01 -07:00
Junio C Hamano
d011ab4312 Merge branch 'maint-1.8.1' into maint
* 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-27 10:51:10 -07:00
Mihai Capotă
38ef8a76e7 git-pull doc: fix grammo ("conflicts" is plural)
Signed-off-by: Mihai Capotă <mihai@mihaic.ro>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27 09:30:54 -07:00
Thomas Ackermann
2de9b71138 Documentation: the name of the system is 'Git', not 'git'
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01 13:53:33 -08:00
Miklos Vajna
d9aa361043 man: git pull -r is a short for --rebase
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-08-17 00:26:52 -07:00
Jeff King
6cf378f0cb docs: stop using asciidoc no-inline-literal
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>
2012-04-26 13:19:06 -07:00
Junio C Hamano
1ee740e669 Merge branch 'ab/pull-rebase-config'
* ab/pull-rebase-config:
  pull: introduce a pull.rebase option to enable --rebase
2011-12-09 13:37:01 -08:00
Ævar Arnfjörð Bjarmason
6b37dff17f pull: introduce a pull.rebase option to enable --rebase
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-11-07 08:43:11 -08:00
Martin von Zweigbergk
7791a1d9b9 Documentation: use [verse] for SYNOPSIS sections
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-07-06 14:26:26 -07:00
Junio C Hamano
2071fb015b Merge branch 'jl/submodule-fetch-on-demand'
* 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-04-04 15:02:01 -07:00
Jeff King
48bb914ed6 doc: drop author/documentation sections from most pages
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-11 10:59:16 -05:00
Jens Lehmann
794a3592ad fetch/pull: Describe --recurse-submodule restrictions in the BUGS section
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-09 13:10:36 -08:00
Jens Lehmann
8f0700dd33 fetch/pull: Add the 'on-demand' value to the --recurse-submodules option
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-03-09 13:10:35 -08:00
Jens Lehmann
7811d9600f pull: Document the "--[no-]recurse-submodules" options
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>
2011-02-07 15:19:09 -08:00
Junio C Hamano
b5c1781430 Merge branch 'ja/maint-pull-rebase-doc'
* ja/maint-pull-rebase-doc:
  git-pull.txt: Mention branch.autosetuprebase
2010-12-12 21:49:53 -08:00
Junio C Hamano
b281796eeb Merge branch 'maint' to sync with Git 1.7.3.3
* 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-03 15:23:55 -08:00
Jonathan Nieder
3bae8d4da1 Documentation: do not misinterpret pull refspec as bold text
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-03 15:22:52 -08:00
Jari Aalto
c4f4157ee8 git-pull.txt: Mention branch.autosetuprebase
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-12-03 11:16:45 -08:00
Junio C Hamano
786f174dab Merge branch 'mm/phrase-remote-tracking'
* 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-24 15:55:05 -08:00
Martin von Zweigbergk
11fe3f73cc Documentation/git-pull: clarify configuration
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-17 13:17:46 -08:00
Matthieu Moy
8b3f3f84b2 Change "tracking branch" to "remote-tracking branch"
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-03 09:20:41 -07:00
Matthieu Moy
0e615b252f Replace "remote tracking" with "remote-tracking"
"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-11-03 09:19:04 -07:00
Jonathan Nieder
3f8fc184c0 Documentation: flesh out “git pull” description
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-08-02 15:48:18 -07:00
Tay Ray Chuan
9839018e87 fetch and pull: learn --progress
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-24 08:35:45 -08:00
Tay Ray Chuan
409b8d82df Documentation/git-pull: put verbosity options before merge/fetch ones
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-02-24 08:35:43 -08:00
Thomas Rast
0b444cdb19 Documentation: spell 'git cmd' without dash throughout
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-10 13:01:28 +01:00
Thomas Rast
e330d8ca1a Documentation: warn prominently against merging with dirty trees
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>
2010-01-09 21:08:26 +01:00
Junio C Hamano
b7eb912b0d Merge branch 'ja/fetch-doc'
* ja/fetch-doc:
  Documentation/merge-options.txt: order options in alphabetical groups
  Documentation/git-pull.txt: Add subtitles above included option files
  Documentation/fetch-options.txt: order options alphabetically
2009-10-30 20:05:47 -07:00
Jari Aalto
3f7a9b5ad1 Documentation/git-pull.txt: Add subtitles above included option files
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-22 12:39:10 -07:00