Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Apr 28, 2011
  1. @gitster

    Merge branch 'mz/rebase'

    gitster authored
    * mz/rebase: (34 commits)
      rebase: define options in OPTIONS_SPEC
      Makefile: do not install sourced rebase scripts
      rebase: use @{upstream} if no upstream specified
      rebase -i: remove unnecessary state rebase-root
      rebase -i: don't read unused variable preserve_merges
      git-rebase--am: remove unnecessary --3way option
      rebase -m: don't print exit code 2 when merge fails
      rebase -m: remember allow_rerere_autoupdate option
      rebase: remember strategy and strategy options
      rebase: remember verbose option
      rebase: extract code for writing basic state
      rebase: factor out sub command handling
      rebase: make -v a tiny bit more verbose
      rebase -i: align variable names
      rebase: show consistent conflict resolution hint
      rebase: extract am code to new source file
      rebase: extract merge code to new source file
      rebase: remove $branch as synonym for $orig_head
      rebase -i: support --stat
      rebase: factor out call to pre-rebase hook
Commits on Apr 4, 2011
  1. @gitster

    Merge branch 'jl/submodule-fetch-on-demand'

    gitster authored
    * 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
Commits on Mar 25, 2011
  1. @peff @gitster

    pull: do not clobber untracked files on initial pull

    peff authored gitster committed
    For a pull into an unborn branch, we do not use "git merge"
    at all. Instead, we call read-tree directly. However, we
    used the --reset parameter instead of "-m", which turns off
    the safety features.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Mar 20, 2011
  1. @gitster

    Merge branch 'jk/merge-rename-ux'

    gitster authored
    * jk/merge-rename-ux:
      pull: propagate --progress to merge
      merge: enable progress reporting for rename detection
      add inexact rename detection progress infrastructure
      commit: stop setting rename limit
      bump rename limit defaults (again)
      merge: improve inexact rename limit warning
Commits on Mar 9, 2011
  1. @jlehmann @gitster

    fetch/pull: Add the 'on-demand' value to the --recurse-submodules option

    jlehmann authored gitster committed
    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 <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 21, 2011
  1. @peff @gitster

    pull: propagate --progress to merge

    peff authored gitster committed
    Now that merge understands progress, we should pass it
    along. While we're at it, pass along --no-progress, too.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 15, 2011
  1. @mjg @gitster

    pull: do not display fetch usage on --help-all

    mjg authored gitster committed
    Currently, "git pull --help-all" displays the fetch usage info.
    Make it equivalent to "git pull -h" instead since "--help-all" is
    documented in gitcli(7).
    Do not try to sanitize the pull option parser (aka last hair puller).
    Signed-off-by: Michael J Gruber <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 10, 2011
  1. @gitster

    rebase: use @{upstream} if no upstream specified

    Martin von Zweigbergk authored gitster committed
    'git rebase' without arguments is currently not supported. Make it
    default to 'git rebase @{upstream}'. That is also what 'git pull
    [--rebase]' defaults to, so it only makes sense that 'git rebase'
    defaults to the same thing.
    Defaulting to @{upstream} will make it possible to run e.g. 'git
    rebase -i' without arguments, which is probably a quite common use
    case. It also improves the scenario where you have multiple branches
    that rebase against a remote-tracking branch, where you currently have
    to choose between the extra network delay of 'git pull' or the
    slightly awkward keys to enter 'git rebase @{u}'.
    The error reporting when no upstream is configured for the current
    branch or when no branch is checked out is reused from A
    function is extracted into for this purpose.
    Helped-by: Yann Dirson <>
    Helped-by: Jonathan Nieder <>
    Signed-off-by: Martin von Zweigbergk <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 16, 2010
  1. @gitster

    Merge branch 'jl/fetch-submodule-recursive'

    gitster authored
    * jl/fetch-submodule-recursive:
      fetch_populated_submodules(): document dynamic allocation
      Submodules: Add the "fetchRecurseSubmodules" config option
      Add the 'fetch.recurseSubmodules' config setting
      fetch/pull: Add the --recurse-submodules option
Commits on Nov 12, 2010
  1. @jlehmann @gitster

    Add the 'fetch.recurseSubmodules' config setting

    jlehmann authored gitster committed
    This new boolean option can be used to override the default for "git
    fetch" and "git pull", which is to not recurse into populated submodules
    and fetch all new commits there too.
    Signed-off-by: Jens Lehmann <>
    Signed-off-by: Junio C Hamano <>
  2. @jlehmann @gitster

    fetch/pull: Add the --recurse-submodules option

    jlehmann authored gitster committed
    Until now you had to call "git submodule update" (without -N|--no-fetch
    option) or something like "git submodule foreach git fetch" to fetch
    new commits in populated submodules from their remote.
    This could lead to "(commits not present)" messages in the output of
    "git diff --submodule" (which is used by "git gui" and "gitk") after
    fetching or pulling new commits in the superproject and is an obstacle for
    implementing recursive checkout of submodules. Also "git submodule
    update" cannot fetch changes when disconnected, so it was very easy to
    forget to fetch the submodule changes before disconnecting only to
    discover later that they are needed.
    This patch adds the "--recurse-submodules" option to recursively fetch
    each populated submodule from the url configured in the .git/config of the
    submodule at the end of each "git fetch" or during "git pull" in the
    superproject. The submodule paths are taken from the index.
    The hidden option "--submodule-prefix" is added to "git fetch" to be able
    to print out the full paths of nested submodules.
    Signed-off-by: Jens Lehmann <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 28, 2010
  1. @artagnon @gitster

    Porcelain scripts: Rewrite cryptic "needs update" error message

    artagnon authored gitster committed
    Although Git interally has the facility to differentiate between
    porcelain and plubmbing commands and appropriately print errors,
    several shell scripts invoke plubming commands triggering cryptic
    plumbing errors to be displayed on a porcelain interface. This patch
    replaces the "needs update" message in git-pull and git-rebase, when
    `git update-index` is run, with a more friendly message.
    Reported-by: Joshua Jensen <>
    Reported-by: Thore Husfeldt <>
    Signed-off-by: Ramkumar Ramachandra <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 22, 2010
  1. @gitster

    Merge branch 'en/rebase-against-rebase-fix'

    gitster authored
    * en/rebase-against-rebase-fix:
      pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches
      t5520-pull: Add testcases showing spurious conflicts from git pull --rebase
Commits on Aug 13, 2010
  1. @newren @gitster

    pull --rebase: Avoid spurious conflicts and reapplying unnecessary pa…

    newren authored gitster committed
    Prior to c85c792 (pull --rebase: be cleverer with rebased upstream
    branches, 2008-01-26), pull --rebase would run
      git rebase $merge_head
    which resulted in a call to
      git format-patch ... --ignore-if-in-upstream $merge_head..$cur_branch
    This resulted in patches from $merge_head..$cur_branch being applied, as
    long as they did not already exist in $cur_branch..$merge_head.
    Unfortunately, when upstream is rebased, $merge_head..$cur_branch also
    refers to "old" commits that have already been rebased upstream, meaning
    that many patches that were already fixed upstream would be reapplied.
    This could result in many spurious conflicts, as well as reintroduce
    patches that were intentionally dropped upstream.
    So the algorithm was changed in c85c792 (pull --rebase: be cleverer with
    rebased upstream branches, 2008-01-26) and d44e712 (pull: support rebased
    upstream + fetch + pull --rebase, 2009-07-19).  Defining $old_remote_ref to
    be the most recent entry in the reflog for @{upstream} that is an ancestor
    of $cur_branch, pull --rebase was changed to run
      git rebase --onto $merge_head $old_remote_ref
    which results in a call to
      git format-patch ... --ignore-if-in-upstream $old_remote_ref..$cur_branch
    The whole point of this change was to reduce the number of commits being
    reapplied, by avoiding commits that upstream already has or had.
    In the rebased upstream case, this change achieved that purpose.  It is
    worth noting, though, that since $old_remote_ref is always an ancestor of
    $cur_branch (by its definition), format-patch will not know what upstream
    is and thus will not be able to determine if any patches are already
    upstream; they will all be reapplied.
    In the non-rebased upstream case, this new form is usually the same as the
    original code but in some cases $old_remote_ref can be an ancestor of
       $(git merge-base $merge_head $cur_branch)
    meaning that instead of avoiding reapplying commits that upstream already
    has, it actually includes more such commits.  Combined with the fact that
    format-patch can no longer detect commits that are already upstream (since
    it is no longer told what upstream is), results in lots of confusion for
    users (e.g. "git is giving me lots of conflicts in stuff I didn't even
    change since my last push.")
    Cases where additional commits could be reapplied include forking from a
    commit other than the tracking branch, or amending/rebasing after pushing.
    Cases where the inability to detect upstreamed commits cause problems
    include independent discovery of a fix and having your patches get
    upstreamed by some alternative route (e.g. pulling your changes to a third
    machine, pushing from there, and then going back to your original machine
    and trying to pull --rebase).
    Fix the non-rebased upstream case by ignoring $old_remote_ref whenever it
    is contained in $(git merge-base $merge_head $cur_branch).  This should
    have no affect on the rebased upstream case.
    Acked-by: Santi Béjar <>
    Signed-off-by: Elijah Newren <>
    Signed-off-by: Junio C Hamano <>
Commits on May 25, 2010
  1. @peff @gitster

    pull: do nothing on --dry-run

    peff authored gitster committed
    Pull was never meant to take --dry-run at all. However, it
    passes unknown arguments to git-fetch, which does do a
    dry-run. Unfortunately, pull then attempts to merge whatever
    cruft was in FETCH_HEAD (which the dry-run fetch will not
    have written to).
    Even though we never advertise --dry-run as something that
    should work, it is still worth being defensive because:
      1. Other commands (including fetch) take --dry-run, so a
         user might try it.
      2. Rather than simply producing an error, it actually
         changes the repository in totally unexpected ways.
    This patch makes "pull --dry-run" equivalent to "fetch
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Mar 20, 2010
  1. @gitster

    Merge branch 'maint'

    gitster authored
    * maint:
      Update draft release notes to
      fetch: Fix minor memory leak
      fetch: Future-proof initialization of a refspec on stack
      fetch: Check for a "^{}" suffix with suffixcmp()
      daemon: parse_host_and_port SIGSEGV if port is specified
      Makefile: Fix CDPATH problem
      pull: replace unnecessary sed invocation
  2. @bebarino @gitster

    pull: replace unnecessary sed invocation

    bebarino authored gitster committed
    Getting the shortened branch name is as easy as using the shell's
    parameter expansion.
    Signed-off-by: Stephen Boyd <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 24, 2010
  1. @rctay @gitster

    fetch and pull: learn --progress

    rctay authored gitster committed
    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 <>
    Signed-off-by: Junio C Hamano <>
Commits on Jan 24, 2010
  1. @gitster

    pull: re-fix command line generation

    gitster authored
    14e5d40 (pull: Fix parsing of -X<option>, 2010-01-17) forgot that
    merge_name needs to stay as a single non-interpolated string.
    Signed-off-by: Junio C Hamano <>
Commits on Jan 21, 2010
  1. @gitster

    Merge branch 'ap/merge-backend-opts'

    gitster authored
    * 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
Commits on Jan 18, 2010
  1. @gitster

    pull: Fix parsing of -X<option>

    gitster authored
    As -X parameter can contain arbitrary $IFS characters, we need to
    properly quote it from the shell while forming the command line.
    Signed-off-by: Junio C Hamano <>
  2. @apenwarr @gitster

    Teach git-pull to pass -X<option> to git-merge

    apenwarr authored gitster committed
    This needs the usual sq then eval trick to allow IFS characters
    in the option.
    Signed-off-by: Avery Pennarun <>
    Signed-off-by: Junio C Hamano <>
Commits on Jan 12, 2010
  1. @moy @gitster

    Be more user-friendly when refusing to do something because of conflict.

    moy authored gitster committed
    Various commands refuse to run in the presence of conflicts (commit,
    merge, pull, cherry-pick/revert). They all used to provide rough, and
    inconsistant error messages.
    A new variable advice.resolveconflict is introduced, and allows more
    verbose messages, pointing the user to the appropriate solution.
    For commit, the error message used to look like this:
    $ git commit
    foo.txt: needs merge
    foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
    foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
    foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
    error: Error building trees
    The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
    option to make the output more consistant with the other porcelain
    commands, and catch the error in return, to stop with a clean error
    message. The next lines were displayed by a call to cache_tree_update(),
    which is not reached anymore if we noticed the conflict.
    The new output looks like:
    U       foo.txt
    fatal: 'commit' is not possible because you have unmerged files.
    Please, fix them up in the work tree, and then use 'git add/rm <file>' as
    appropriate to mark resolution and make a commit, or use 'git commit -a'.
    Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
    exists instead of waiting for merge to complain.
    The behavior of merge and the test-case are slightly modified to reflect
    the usual flow: start with conflicts, fix them, and afterwards get rid of
    MERGE_HEAD, with different error messages at each stage.
    Signed-off-by: Matthieu Moy <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 9, 2009
  1. @gitster

    Merge branch 'maint'

    gitster authored
    * maint:
      add-interactive: fix deletion of non-empty files
      pull: clarify advice for the unconfigured error case
Commits on Dec 8, 2009
  1. @gitster

    Revert recent "git merge <msg> HEAD <commit>..." deprecation

    gitster authored
    This reverts commit c0ecb07 "
    Fix call to git-merge for new command format" and
    commit b81e00a "git-merge: a deprecation
    notice of the ancient command line syntax".
    They caused a "git pull" (without any arguments, and without any local
    commits---only to update to the other side) to warn that commit log
    message is ignored because the merge resulted in a fast-forward.
    Another possible solution is to add an extra option to "git merge" so that
    "git pull" can tell it that the message given is not coming from the end
    user (the canned message is passed just in case the merge resulted in a
    non-ff and caused commit), but I think it is easier _not_ to deprecate the
    old syntax.
    Signed-off-by: Junio C Hamano <>
Commits on Dec 3, 2009
  1. @jast @gitster

    pull: clarify advice for the unconfigured error case

    jast authored gitster committed
    When pull --rebase fails because it cannot find what branch to
    merge against, the error message implies we are trying to merge.
    Say "rebase against" instead of "merge with" to avoid confusion.
    The configuration suggested to remedy the situation uses a
    confusing syntax, with variables specified in the dotted form
    accepted by 'git config' but separated from their values by the
    '=' delimiter used by config files.  Since the user will have to
    edit this output anyway, it is more helpful to provide a config
    file snippet to paste into an editor and modify.
    Signed-off-by: Jan Krüger <>
    Signed-off-by: Jonathan Nieder <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 2, 2009
  1. @vonbrand @gitster Fix call to git-merge for new command format

    vonbrand authored gitster committed
    Now "git merge <msg> HEAD" is officially deprecated, we should
    clean our own use as well.
    Signed-off-by: Horst H. von Brand <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 16, 2009
  1. @gitster

    Merge branch 'fc/doc-fast-forward'

    gitster authored
    * fc/doc-fast-forward:
      Use 'fast-forward' all over the place
Commits on Oct 30, 2009
  1. @bjorng @gitster

    Teach 'git merge' and 'git pull' the option --ff-only

    bjorng authored gitster committed
    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 <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 25, 2009
  1. @felipec @gitster

    Use 'fast-forward' all over the place

    felipec authored gitster committed
    It's a compound word.
    Signed-off-by: Felipe Contreras <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 9, 2009
  1. @peff @gitster

    pull: improve advice for unconfigured error case

    peff authored gitster committed
    There are several reasons a git-pull invocation might not
    have anything marked for merge:
      1. We're not on a branch, so there is no branch
      2. We're on a branch, but there is no configuration for
         this branch.
      3. We fetched from the configured remote, but the
         configured branch to merge didn't get fetched (either
         it doesn't exist, or wasn't part of the fetch refspec).
      4. We fetched from the non-default remote, but didn't
         specify a branch to merge. We can't use the configured
         one because it applies to the default remote.
      5. We fetched from a specified remote, and a refspec was
         given, but it ended up not fetching anything (this is
         actually hard to do; if the refspec points to a remote
         branch and it doesn't exist, then fetch will fail and
         we never make it to this code path. But if you provide
         a wildcard refspec like
         then you can see this failure).
    We have handled (1) and (2) for some time. Recently, commit
    a6dbf88 added code to handle case (3).
    This patch handles cases (4) and (5), which previously just
    fell under other cases, producing a confusing message.
    While we're at it, let's rewrap the text for case (3), which
    looks terribly ugly as it is.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 5, 2009
  1. @gitster

    git-pull: dead code removal

    gitster authored
    Back when a74b170 (git-pull: disallow implicit merging to detached HEAD,
    2007-01-15) added this check, $? referred to the error status of reading
    HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase,
    2007-11-28) moved the command away from where the check is, and nobody
    noticed the breakage.  Ever since, $? has always been 0 (tr at the end of
    the pipe to find merge_head never fails) and other case arms were never
    These days, error_on_no_merge_candidates function is prepared to handle a
    detached HEAD case, which was what the code this patch removes used to
    Signed-off-by: Junio C Hamano <>
Commits on Sep 23, 2009
  1. @gitster

    pull: Clarify "helpful" message for another corner case

    gitster authored
    When the remote branch we asked for merging did not exist in the set of
    fetched refs, we unconditionally hinted that it was because of lack of
    configuration.  It is not necessarily so, and risks sending users for a
    wild goose chase.
    Make sure to check if that is indeed the case before telling a wild guess
    to the user.
    Signed-off-by: Junio C Hamano <>
Commits on Aug 12, 2009
  1. @peff @gitster

    allow pull --rebase on branch yet to be born

    peff authored gitster committed
    When doing a "pull --rebase", we check to make sure that the index and
    working tree are clean. The index-clean check compares the index against
    HEAD. The test erroneously reports dirtiness if we don't have a HEAD yet.
    In such an "unborn branch" case, by definition, a non-empty index won't
    be based on whatever we are pulling down from the remote, and will lose
    the local change.  Just check if $GIT_DIR/index exists and error out.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Jul 19, 2009
  1. @gitster

    pull: support rebased upstream + fetch + pull --rebase

    Santi Béjar authored gitster committed
    You cannot do a "git pull --rebase" with a rebased upstream, if you have
    already run "git fetch".  Try to behave as if the "git fetch" was not run.
    In other words, find the fork point of the current branch, where
    the tip of upstream branch used to be, and use it as the upstream
    parameter of "git rebase".
    This patch computes the fork point by walking the reflog to find the first
    commit which is an ancestor of the current branch.  Maybe there are
    smarter ways to compute it, but this is a straight forward implementation.
    Signed-off-by: Santi Béjar <>
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.