Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jun 2, 2015
  1. @pyokagan @gitster

    pull: use git-rev-parse --parseopt for option parsing

    pyokagan authored gitster committed
    To enable unambiguous parsing of abbreviated options, bundled short
    options, separate form options and to provide consistent usage help, use
    git-rev-parse --parseopt for option parsing. With this, simplify the
    option parsing code.
    
    Signed-off-by: Paul Tan <pyokagan@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @pyokagan @gitster

    pull: handle git-fetch's options as well

    pyokagan authored gitster committed
    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>
Commits on May 26, 2015
  1. @gitster

    Merge branch 'pt/pull-ff-vs-merge-ff'

    gitster authored
    The pull.ff configuration was supposed to override the merge.ff
    configuration, but it didn't.
    
    * pt/pull-ff-vs-merge-ff:
      pull: parse pull.ff as a bool or string
      pull: make pull.ff=true override merge.ff
  2. @gitster

    Merge branch 'pt/pull-log-n'

    gitster authored
    "git pull --log" and "git pull --no-log" worked as expected, but
    "git pull --log=20" did not.
    
    * pt/pull-log-n:
      pull: handle --log=<n>
Commits on May 22, 2015
  1. @gitster

    Merge branch 'pt/pull-tags-error-diag'

    gitster authored
    There was a dead code that used to handle "git pull --tags" and
    show special-cased error message, which was made irrelevant when
    the semantics of the option changed back in Git 1.9 days.
    
    * pt/pull-tags-error-diag:
      pull: remove --tags error in no merge candidates case
Commits on May 19, 2015
  1. @gitster

    Merge branch 'jc/merge'

    gitster authored
    "git merge FETCH_HEAD" learned that the previous "git fetch" could
    be to create an Octopus merge, i.e. recording multiple branches
    that are not marked as "not-for-merge"; this allows us to lose an
    old style invocation "git merge <msg> HEAD $commits..." in the
    implementation of "git pull" script; the old style syntax can now
    be deprecated.
    
    * jc/merge:
      merge: deprecate 'git merge <message> HEAD <commit>' syntax
      merge: handle FETCH_HEAD internally
      merge: decide if we auto-generate the message early in collect_parents()
      merge: make collect_parents() auto-generate the merge message
      merge: extract prepare_merge_message() logic out
      merge: narrow scope of merge_names
      merge: split reduce_parents() out of collect_parents()
      merge: clarify collect_parents() logic
      merge: small leakfix and code simplification
      merge: do not check argc to determine number of remote heads
      merge: clarify "pulling into void" special case
      t5520: test pulling an octopus into an unborn branch
      t5520: style fixes
      merge: simplify code flow
      merge: test the top-level merge driver
Commits on May 18, 2015
  1. @pyokagan @gitster

    pull: parse pull.ff as a bool or string

    pyokagan authored gitster committed
    Since b814da8 (pull: add pull.ff configuration, 2014-01-15) git-pull
    supported setting --(no-)ff via the pull.ff configuration value.
    However, as it only matches the string values of "true" and "false", it
    does not support other boolean aliases such as "on", "off", "1", "0".
    This is inconsistent with the merge.ff setting, which supports these
    aliases.
    
    Fix this by using the bool_or_string_config function to retrieve the
    value of pull.ff.
    
    Signed-off-by: Paul Tan <pyokagan@gmail.com>
    Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @pyokagan @gitster

    pull: make pull.ff=true override merge.ff

    pyokagan authored gitster committed
    Since b814da8 (pull: add pull.ff configuration, 2014-01-15), running
    git-pull with the configuration pull.ff=false or pull.ff=only is
    equivalent to passing --no-ff and --ff-only to git-merge. However, if
    pull.ff=true, no switch is passed to git-merge. This leads to the
    confusing behavior where pull.ff=false or pull.ff=only is able to
    override merge.ff, while pull.ff=true is unable to.
    
    Fix this by adding the --ff switch if pull.ff=true, and add a test to
    catch future regressions.
    
    Furthermore, clarify in the documentation that pull.ff overrides
    merge.ff.
    
    Signed-off-by: Paul Tan <pyokagan@gmail.com>
    Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @pyokagan @gitster

    pull: handle --log=<n>

    pyokagan authored gitster committed
    Since efb779f (merge, pull: add '--(no-)log' command line option,
    2008-04-06) git-pull supported the (--no-)log switch and would pass it
    to git-merge.
    
    96e9420 (merge: Make '--log' an integer option for number of shortlog
    entries, 2010-09-08) implemented support for the --log=<n> switch, which
    would explicitly set the number of shortlog entries. However, git-pull
    does not recognize this option, and will instead pass it to git-fetch,
    leading to "unknown option" errors.
    
    Fix this by matching --log=* in addition to --log and --no-log.
    
    Implement a test for this use case.
    
    Signed-off-by: Paul Tan <pyokagan@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on May 14, 2015
  1. @pyokagan @gitster

    pull: remove --tags error in no merge candidates case

    pyokagan authored gitster committed
    Since 441ed41 ("git pull --tags": error out with a better message.,
    2007-12-28), git pull --tags would print a different error message if
    git-fetch did not return any merge candidates:
    
       It doesn't make sense to pull all tags; you probably meant:
            git fetch --tags
    
    This is because at that time, git-fetch --tags would override any
    configured refspecs, and thus there would be no merge candidates. The
    error message was thus introduced to prevent confusion.
    
    However, since c5a84e9 (fetch --tags: fetch tags *in addition to*
    other stuff, 2013-10-30), git fetch --tags would fetch tags in addition
    to any configured refspecs. Hence, if any no merge candidates situation
    occurs, it is not because --tags was set. As such, this special error
    message is now irrelevant.
    
    To prevent confusion, remove this error message.
    
    Signed-off-by: Paul Tan <pyokagan@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Apr 29, 2015
  1. @gitster

    merge: deprecate 'git merge <message> HEAD <commit>' syntax

    gitster authored
    We had this in "git merge" manual for eternity:
    
        'git merge' <msg> HEAD <commit>...
    
        [This] syntax (<msg> `HEAD` <commit>...) is supported for
        historical reasons.  Do not use it from the command line or in
        new scripts.  It is the same as `git merge -m <msg> <commit>...`.
    
    With the update to "git merge" to make it understand what is
    recorded in FETCH_HEAD directly, including Octopus merge cases, we
    now can rewrite the use of this syntax in "git pull" with a simple
    "git merge FETCH_HEAD".
    
    Also there are quite a few fallouts in the test scripts, and it
    turns out that "git cvsimport" also uses this old syntax to record
    a merge.
    
    Judging from this result, I would not be surprised if dropping the
    support of the old syntax broke scripts people have written and been
    relying on for the past ten years.  But at least we can start the
    deprecation process by throwing a warning message when the syntax is
    used.
    
    With luck, we might be able to drop the support in a few years.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 1, 2014
  1. @pclouds @gitster

    *.sh: respect $GIT_INDEX_FILE

    pclouds authored gitster committed
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Aug 28, 2014
  1. @moy @gitster

    merge, pull: stop advising 'commit -a' in case of conflict

    moy authored gitster committed
    'git commit -a' is rarely a good way to mark conflicts as resolved:
    the user anyway has to go manually through the list of conflicts to
    do the actual resolution, and it is usually better to use "git add"
    on each files after doing the resolution.
    
    On the other hand, using 'git commit -a' is potentially dangerous,
    as it makes it very easy to mistakenly commit conflict markers
    without noticing, and even worse, the user may have started a merge
    while having local changes that do not overlap with it in the
    working tree.
    
    While we're there, synchronize the 'git pull' and 'git merge'
    messages: the first was ending with '...  and make a commit.', but
    not the latter.
    
    Eventually, git should detect that conflicts have been resolved in
    the working tree and tailor these messages further.  Not only "use
    git commit -a" could be resurected, but "Fix them up in the work
    tree" should be dropped when it happens.
    
    Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jun 12, 2014
  1. @gitster

    Sync with maint

    gitster authored
    * maint:
      pull: do not abuse 'break' inside a shell 'case'
  2. @Jajcus @gitster

    pull: do not abuse 'break' inside a shell 'case'

    Jajcus authored gitster committed
    It is not C. The code would break under mksh when 'pull.ff' is set:
    
      $ git pull
      /usr/lib/git-core/git-pull[67]: break: can't break
      Already up-to-date.
    
    Signed-off-by: Jacek Konieczny <jajcus@jajcus.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Apr 23, 2014
  1. @devzero2000 @gitster

    git-pull.sh: use the $( ... ) construct for command substitution

    devzero2000 authored gitster committed
    The Git CodingGuidelines prefer the $(...) construct for command
    substitution instead of using the backquotes `...`.
    
    The backquoted form is the traditional method for command
    substitution, and is supported by POSIX.  However, all but the
    simplest uses become complicated quickly.  In particular, embedded
    command substitutions and/or the use of double quotes require
    careful escaping with the backslash character.
    
    The patch was generated by:
    
    for _f in $(find . -name "*.sh")
    do
       sed -i 's@`\(.*\)`@$(\1)@g' ${_f}
    done
    
    and then carefully proof-read.
    
    Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
    Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 27, 2014
  1. @gitster

    Merge branch 'bc/gpg-sign-everywhere'

    gitster authored
    Teach "--gpg-sign" option to many commands that create commits.
    
    * bc/gpg-sign-everywhere:
      pull: add the --gpg-sign option.
      rebase: add the --gpg-sign option
      rebase: parse options in stuck-long mode
      rebase: don't try to match -M option
      rebase: remove useless arguments check
      am: add the --gpg-sign option
      am: parse options in stuck-long mode
      git-sh-setup.sh: add variable to use the stuck-long mode
      cherry-pick, revert: add the --gpg-sign option
  2. @gitster

    Merge branch 'da/pull-ff-configuration'

    gitster authored
    "git pull" learned to pay attention to pull.ff configuration
    variable.
    
    * da/pull-ff-configuration:
      pull: add --ff-only to the help text
      pull: add pull.ff configuration
Commits on Feb 11, 2014
  1. @bk2204 @gitster

    pull: add the --gpg-sign option.

    bk2204 authored gitster committed
    git merge already allows us to sign commits, and git rebase has recently
    learned how to do so as well.  Teach git pull to parse the -S/--gpg-sign
    option and pass this along to merge or rebase, as appropriate.
    
    Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jan 17, 2014
  1. @gitster

    Merge branch 'jk/pull-rebase-using-fork-point'

    gitster authored
    Finishing touches so that an expected error message will not leak to
    the UI.
    
    * jk/pull-rebase-using-fork-point:
      pull: suppress error when no remoteref is found
  2. @johnkeeping @gitster

    pull: suppress error when no remoteref is found

    johnkeeping authored gitster committed
    Commit 48059e4 (pull: use merge-base --fork-point when appropriate,
    2013-12-08) incorrectly assumes that get_remote_merge_branch will either
    yield a non-empty string or return an error, but there are circumstances
    where it will yield an empty string.
    
    The previous code then invoked git-rev-list with no arguments, which
    results in an error suppressed by redirecting stderr to /dev/null.  Now
    we invoke git-merge-base with an empty branch name, which also results
    in an error.  Suppress this in the same way.
    
    Signed-off-by: John Keeping <john@keeping.me.uk>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jan 16, 2014
  1. @davvid @gitster

    pull: add --ff-only to the help text

    davvid authored gitster committed
    Signed-off-by: David Aguilar <davvid@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @davvid @gitster

    pull: add pull.ff configuration

    davvid authored gitster committed
    Add a `pull.ff` configuration option that is analogous
    to the `merge.ff` option.
    
    This allows us to control the fast-forward behavior for
    pull-initiated merges only.
    
    Signed-off-by: David Aguilar <davvid@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 27, 2013
  1. @gitster

    Merge branch 'jk/pull-rebase-using-fork-point'

    gitster authored
    * jk/pull-rebase-using-fork-point:
      rebase: use reflog to find common base with upstream
      pull: use merge-base --fork-point when appropriate
Commits on Dec 9, 2013
  1. @johnkeeping @gitster

    pull: use merge-base --fork-point when appropriate

    johnkeeping authored gitster committed
    Since commit d96855f (merge-base: teach "--fork-point" mode, 2013-10-23)
    we can replace a shell loop in git-pull with a single call to
    git-merge-base.  So let's do so.
    
    Signed-off-by: John Keeping <john@keeping.me.uk>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Oct 30, 2013
  1. @mhagger @gitster

    fetch --tags: fetch tags *in addition to* other stuff

    mhagger authored gitster committed
    Previously, fetch's "--tags" option was considered equivalent to
    specifying the refspec "refs/tags/*:refs/tags/*" on the command line;
    in particular, it caused the remote.<name>.refspec configuration to be
    ignored.
    
    But it is not very useful to fetch tags without also fetching other
    references, whereas it *is* quite useful to be able to fetch tags *in
    addition to* other references.  So change the semantics of this option
    to do the latter.
    
    If a user wants to fetch *only* tags, then it is still possible to
    specifying an explicit refspec:
    
        git fetch <remote> 'refs/tags/*:refs/tags/*'
    
    Please note that the documentation prior to 1.8.0.3 was ambiguous
    about this aspect of "fetch --tags" behavior.  Commit
    
        f0cb2f1 2012-12-14 fetch --tags: clarify documentation
    
    made the documentation match the old behavior.  This commit changes
    the documentation to match the new behavior.
    
    Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 17, 2013
  1. @gitster

    Merge branch 'fc/trivial'

    gitster authored
    * fc/trivial:
      pull: use $curr_branch_short more
      add: trivial style cleanup
      reset: trivial style cleanup
      branch: trivial style fix
      reset: trivial refactoring
Commits on Sep 8, 2013
  1. @gitster

    pull: use $curr_branch_short more

    René Scharfe authored gitster committed
    One of the first things git-pull.sh does is setting $curr_branch to
    the target of HEAD and $curr_branch_short to the same but with the
    leading "refs/heads/" removed.  Simplify the code by using
    $curr_branch_short instead of setting $curr_branch to the same
    shortened value.
    
    The only other use of $curr_branch in that function doesn't have to
    be replaced with $curr_branch_short because it just checks if the
    string is empty.  That property is the same with or without the prefix
    unless HEAD points to "refs/heads/" alone, which is invalid.
    
    Noticed-by: Felipe Contreras <felipe.contreras@gmail.com>
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 4, 2013
  1. @stephenh @gitster

    pull: allow pull to preserve merges when rebasing

    stephenh authored gitster committed
    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>
Commits on Jul 12, 2013
  1. @gitster

    Merge branch 'jk/pull-to-integrate'

    gitster authored
    * jk/pull-to-integrate:
      pull: change the description to "integrate" changes
      push: avoid suggesting "merging" remote changes
Commits on Jul 8, 2013
  1. @johnkeeping @gitster

    pull: change the description to "integrate" changes

    johnkeeping authored gitster committed
    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>
Commits on Jun 27, 2013
  1. @gitster

    Merge branch 'jk/pull-into-dirty-unborn'

    gitster authored
    "git pull" into nothing trashed "local changes" that were in the
    index, and this avoids it.
    
    * jk/pull-into-dirty-unborn:
      pull: merge into unborn by fast-forwarding from empty tree
      pull: update unborn branch tip after index
Commits on Jun 20, 2013
  1. @gitster

    pull: merge into unborn by fast-forwarding from empty tree

    Thomas Rast authored gitster committed
    The logic for pulling into an unborn branch was originally
    designed to be used on a newly-initialized repository
    (d09e79c, git-pull: allow pulling into an empty repository,
    2006-11-16).  It thus did not initially deal with
    uncommitted changes in the unborn branch.  The case of an
    _unstaged_ untracked file was fixed by 4b3ffe5 (pull: do not
    clobber untracked files on initial pull, 2011-03-25).
    However, it still clobbered existing staged files, both when
    the file exists in the merged commit (it will be
    overwritten), and when it does not (it will be deleted).
    
    We fix this by doing a two-way merge, where the "current"
    side of the merge is an empty tree, and the "target" side is
    HEAD (already updated to FETCH_HEAD at this point).  This
    amounts to claiming that all work in the index was done vs.
    an empty tree, and thus all content of the index is
    precious.
    
    Note that this use of read-tree just gives us protection
    against overwriting index and working tree changes. It will
    not actually result in a 3-way merge conflict in the index.
    This is fine, as this is a rare situation, and the conflict
    would not be interesting anyway (it must, by definition, be
    an add/add conflict with the whole content conflicting). And
    it makes it simpler for the user to recover, as they have no
    HEAD to "git reset" back to.
    
    Reported-by: Stefan Schüßler <mail@stefanschuessler.de>
    Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @peff @gitster

    pull: update unborn branch tip after index

    peff authored gitster committed
    When commit d09e79c taught git to pull into an unborn
    branch, it first updated the unborn branch to point at the
    pulled commit, and then used read-tree to update the index
    and working tree. That ordering made sense, since any
    failure of the latter step would be due to filesystem
    errors, and one could then recover with "git reset --hard".
    
    Later, commit 4b3ffe5 added extra safety for existing files
    in the working tree by asking read-tree to bail out when it
    would overwrite such a file. This error mode is much less
    "your pull failed due to random errors" and more like "we
    reject this pull because it would lose data". In that case,
    it makes sense not to update the HEAD ref, just as a regular
    rejected merge would do.
    
    This patch reverses the order of the update-ref and
    read-tree calls, so that we do not touch the HEAD ref at all if a
    merge is rejected. This also means that we would not update
    HEAD in case of a transient filesystem error, but those are
    presumably less rare (and one can still recover by repeating
    the pull, or by accessing FETCH_HEAD directly).
    
    While we're reorganizing the code, we can drop the "exit 1"
    from the end of our command chain. We exit immediately
    either way, and just calling exit without an argument will
    use the exit code from the last command.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Apr 1, 2013
  1. @gitster

    merge/pull: verify GPG signatures of commits being merged

    Sebastian Götte authored gitster committed
    When --verify-signatures is specified on the command-line of git-merge
    or git-pull, check whether the commits being merged have good gpg
    signatures and abort the merge in case they do not. This allows e.g.
    auto-deployment from untrusted repo hosts.
    
    Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something went wrong with that request. Please try again.