2005-04-18 21:15:10 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
2005-08-23 06:57:59 +02:00
|
|
|
# Copyright (c) 2005 Junio C Hamano
|
|
|
|
|
#
|
|
|
|
|
# Fetch one or more remote refs and merge it/them into the current HEAD.
|
|
|
|
|
|
2013-08-13 05:43:42 +02:00
|
|
|
USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] [--[no-]rebase|--rebase=preserve] [-s strategy]... [<fetch-options>] <repo> <head>...'
|
2013-07-07 21:02:15 +02:00
|
|
|
LONG_USAGE='Fetch one or more remote refs and integrate it/them with the current HEAD.'
|
2007-01-12 21:52:03 +01:00
|
|
|
SUBDIRECTORY_OK=Yes
|
2007-11-06 10:50:02 +01:00
|
|
|
OPTIONS_SPEC=
|
2005-11-24 09:12:11 +01:00
|
|
|
. git-sh-setup
|
2011-05-21 20:43:54 +02:00
|
|
|
. git-sh-i18n
|
2011-07-29 09:19:26 +02:00
|
|
|
set_reflog_action "pull${1+ $*}"
|
pull,rebase: handle GIT_WORK_TREE better
You can't currently run git-pull or git-rebase from outside
of the work tree, even with GIT_WORK_TREE set, due to an
overeager require_work_tree function. Commit e2eb527
documents this problem and provides the infrastructure for a
fix, but left it to later commits to audit and update
individual scripts.
Changing these scripts to use require_work_tree_exists is
easy to verify. We immediately call cd_to_toplevel, anyway.
Therefore no matter which function we use, the state
afterwards is one of:
1. We have a work tree, and we are at the top level.
2. We don't have a work tree, and we have died.
The only catch is that we must also make sure no code that
ran before the cd_to_toplevel assumed that we were already
in the working tree.
In this case, we will only have included shell libraries and
called set_reflog_action, neither of which care about the
current working directory at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-13 17:59:24 +02:00
|
|
|
require_work_tree_exists
|
2007-01-12 21:52:03 +01:00
|
|
|
cd_to_toplevel
|
2005-08-26 03:15:32 +02:00
|
|
|
|
Be more user-friendly when refusing to do something because of conflict.
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 10:54:44 +01:00
|
|
|
|
|
|
|
|
die_conflict () {
|
|
|
|
|
git diff-index --cached --name-status -r --ignore-submodules HEAD --
|
|
|
|
|
if [ $(git config --bool --get advice.resolveConflict || echo true) = "true" ]; then
|
2011-05-21 20:43:55 +02:00
|
|
|
die "$(gettext "Pull is not possible because you have unmerged files.
|
Be more user-friendly when refusing to do something because of conflict.
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 10:54:44 +01:00
|
|
|
Please, fix them up in the work tree, and then use 'git add/rm <file>'
|
2011-05-21 20:43:55 +02:00
|
|
|
as appropriate to mark resolution, or use 'git commit -a'.")"
|
Be more user-friendly when refusing to do something because of conflict.
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 10:54:44 +01:00
|
|
|
else
|
2011-05-21 20:43:55 +02:00
|
|
|
die "$(gettext "Pull is not possible because you have unmerged files.")"
|
Be more user-friendly when refusing to do something because of conflict.
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 10:54:44 +01:00
|
|
|
fi
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
die_merge () {
|
|
|
|
|
if [ $(git config --bool --get advice.resolveConflict || echo true) = "true" ]; then
|
2011-05-21 20:43:55 +02:00
|
|
|
die "$(gettext "You have not concluded your merge (MERGE_HEAD exists).
|
|
|
|
|
Please, commit your changes before you can merge.")"
|
Be more user-friendly when refusing to do something because of conflict.
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 10:54:44 +01:00
|
|
|
else
|
2011-05-21 20:43:55 +02:00
|
|
|
die "$(gettext "You have not concluded your merge (MERGE_HEAD exists).")"
|
Be more user-friendly when refusing to do something because of conflict.
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 10:54:44 +01:00
|
|
|
fi
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test -z "$(git ls-files -u)" || die_conflict
|
|
|
|
|
test -f "$GIT_DIR/MERGE_HEAD" && die_merge
|
2007-01-01 08:21:50 +01:00
|
|
|
|
2013-08-13 05:43:42 +02:00
|
|
|
bool_or_string_config () {
|
|
|
|
|
git config --bool "$1" 2>/dev/null || git config "$1"
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-29 23:08:31 +01:00
|
|
|
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
|
2013-03-31 18:02:24 +02:00
|
|
|
log_arg= verbosity= progress= recurse_submodules= verify_signatures=
|
2013-08-13 05:43:42 +02:00
|
|
|
merge_args= edit= rebase_args=
|
2007-11-28 14:11:07 +01:00
|
|
|
curr_branch=$(git symbolic-ref -q HEAD)
|
2010-03-18 06:10:45 +01:00
|
|
|
curr_branch_short="${curr_branch#refs/heads/}"
|
2013-08-13 05:43:42 +02:00
|
|
|
rebase=$(bool_or_string_config branch.$curr_branch_short.rebase)
|
2011-11-06 10:50:10 +01:00
|
|
|
if test -z "$rebase"
|
|
|
|
|
then
|
2013-08-13 05:43:42 +02:00
|
|
|
rebase=$(bool_or_string_config pull.rebase)
|
2011-11-06 10:50:10 +01:00
|
|
|
fi
|
2010-05-25 08:07:25 +02:00
|
|
|
dry_run=
|
2007-09-23 22:42:08 +02:00
|
|
|
while :
|
2005-09-26 04:43:51 +02:00
|
|
|
do
|
|
|
|
|
case "$1" in
|
2008-11-15 01:14:24 +01:00
|
|
|
-q|--quiet)
|
2008-11-17 23:09:30 +01:00
|
|
|
verbosity="$verbosity -q" ;;
|
2008-11-15 01:14:24 +01:00
|
|
|
-v|--verbose)
|
2008-11-17 23:09:30 +01:00
|
|
|
verbosity="$verbosity -v" ;;
|
2010-02-24 13:50:28 +01:00
|
|
|
--progress)
|
|
|
|
|
progress=--progress ;;
|
2011-02-20 10:56:56 +01:00
|
|
|
--no-progress)
|
|
|
|
|
progress=--no-progress ;;
|
2008-04-06 03:23:43 +02:00
|
|
|
-n|--no-stat|--no-summary)
|
2009-03-01 22:28:28 +01:00
|
|
|
diffstat=--no-stat ;;
|
2008-04-06 03:23:43 +02:00
|
|
|
--stat|--summary)
|
2009-03-01 22:28:28 +01:00
|
|
|
diffstat=--stat ;;
|
2008-04-06 03:23:46 +02:00
|
|
|
--log|--no-log)
|
|
|
|
|
log_arg=$1 ;;
|
2005-11-02 04:30:11 +01:00
|
|
|
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
|
|
|
|
|
no_commit=--no-commit ;;
|
2007-10-29 09:41:18 +01:00
|
|
|
--c|--co|--com|--comm|--commi|--commit)
|
|
|
|
|
no_commit=--commit ;;
|
2012-02-11 19:21:03 +01:00
|
|
|
-e|--edit)
|
|
|
|
|
edit=--edit ;;
|
|
|
|
|
--no-edit)
|
|
|
|
|
edit=--no-edit ;;
|
git-merge --squash
Some people tend to do many little commits on a topic branch,
recording all the trials and errors, and when the topic is
reasonably cooked well, would want to record the net effect of
the series as one commit on top of the mainline, removing the
cruft from the history. The topic is then abandoned or forked
off again from that point at the mainline.
The barebone porcelainish that comes with core git tools does
not officially support such operation, but you can fake it by
using "git pull --no-merge" when such a topic branch is not a
strict superset of the mainline, like this:
git checkout mainline
git pull --no-commit . that-topic-branch
: fix conflicts if any
rm -f .git/MERGE_HEAD
git commit -a -m 'consolidated commit log message'
git branch -f that-topic-branch ;# now fully merged
This however does not work when the topic branch is a fast
forward of the mainline, because normal "git pull" will never
create a merge commit in such a case, and there is nothing
special --no-commit could do to begin with.
This patch introduces a new option, --squash, to support such a
workflow officially in both fast-forward case and true merge
case. The user-level operation would be the same in both cases:
git checkout mainline
git pull --squash . that-topic-branch
: fix conflicts if any -- naturally, there would be
: no conflict if fast forward.
git commit -a -m 'consolidated commit log message'
git branch -f that-topic-branch ;# now fully merged
When the current branch is already up-to-date with respect to
the other branch, there truly is nothing to do, so the new
option does not have any effect.
This was brought up in #git IRC channel recently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23 10:37:02 +02:00
|
|
|
--sq|--squ|--squa|--squas|--squash)
|
|
|
|
|
squash=--squash ;;
|
2007-10-29 09:41:18 +01:00
|
|
|
--no-sq|--no-squ|--no-squa|--no-squas|--no-squash)
|
|
|
|
|
squash=--no-squash ;;
|
|
|
|
|
--ff)
|
|
|
|
|
no_ff=--ff ;;
|
|
|
|
|
--no-ff)
|
|
|
|
|
no_ff=--no-ff ;;
|
2009-10-29 23:08:31 +01:00
|
|
|
--ff-only)
|
|
|
|
|
ff_only=--ff-only ;;
|
2005-09-26 04:43:51 +02:00
|
|
|
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
|
|
|
|
|
--strateg=*|--strategy=*|\
|
|
|
|
|
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
|
|
|
|
|
case "$#,$1" in
|
|
|
|
|
*,*=*)
|
2006-06-27 18:54:26 +02:00
|
|
|
strategy=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
|
2005-09-26 04:43:51 +02:00
|
|
|
1,*)
|
|
|
|
|
usage ;;
|
|
|
|
|
*)
|
|
|
|
|
strategy="$2"
|
|
|
|
|
shift ;;
|
|
|
|
|
esac
|
|
|
|
|
strategy_args="${strategy_args}-s $strategy "
|
|
|
|
|
;;
|
2009-11-26 03:23:57 +01:00
|
|
|
-X*)
|
|
|
|
|
case "$#,$1" in
|
|
|
|
|
1,-X)
|
|
|
|
|
usage ;;
|
|
|
|
|
*,-X)
|
2010-01-18 07:31:38 +01:00
|
|
|
xx="-X $(git rev-parse --sq-quote "$2")"
|
2009-11-26 03:23:57 +01:00
|
|
|
shift ;;
|
|
|
|
|
*,*)
|
2010-01-18 07:31:38 +01:00
|
|
|
xx=$(git rev-parse --sq-quote "$1") ;;
|
2009-11-26 03:23:57 +01:00
|
|
|
esac
|
|
|
|
|
merge_args="$merge_args$xx "
|
|
|
|
|
;;
|
2013-08-13 05:43:42 +02:00
|
|
|
-r=*|--r=*|--re=*|--reb=*|--reba=*|--rebas=*|--rebase=*)
|
|
|
|
|
rebase="${1#*=}"
|
|
|
|
|
;;
|
2007-11-28 14:11:07 +01:00
|
|
|
-r|--r|--re|--reb|--reba|--rebas|--rebase)
|
|
|
|
|
rebase=true
|
|
|
|
|
;;
|
|
|
|
|
--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
|
|
|
|
|
rebase=false
|
|
|
|
|
;;
|
2010-11-12 13:54:52 +01:00
|
|
|
--recurse-submodules)
|
|
|
|
|
recurse_submodules=--recurse-submodules
|
|
|
|
|
;;
|
2011-03-06 23:11:21 +01:00
|
|
|
--recurse-submodules=*)
|
|
|
|
|
recurse_submodules="$1"
|
|
|
|
|
;;
|
2010-11-11 00:55:02 +01:00
|
|
|
--no-recurse-submodules)
|
|
|
|
|
recurse_submodules=--no-recurse-submodules
|
|
|
|
|
;;
|
2013-03-31 18:02:24 +02:00
|
|
|
--verify-signatures)
|
|
|
|
|
verify_signatures=--verify-signatures
|
|
|
|
|
;;
|
|
|
|
|
--no-verify-signatures)
|
|
|
|
|
verify_signatures=--no-verify-signatures
|
|
|
|
|
;;
|
2010-05-25 08:07:25 +02:00
|
|
|
--d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
|
|
|
|
|
dry_run=--dry-run
|
|
|
|
|
;;
|
2011-10-03 20:21:36 +02:00
|
|
|
-h|--help-all)
|
2005-11-07 06:30:56 +01:00
|
|
|
usage
|
|
|
|
|
;;
|
2007-09-23 22:42:08 +02:00
|
|
|
*)
|
|
|
|
|
# Pass thru anything that may be meant for fetch.
|
2005-10-04 00:45:44 +02:00
|
|
|
break
|
2005-09-26 04:43:51 +02:00
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
shift
|
|
|
|
|
done
|
|
|
|
|
|
2013-08-13 05:43:42 +02:00
|
|
|
case "$rebase" in
|
|
|
|
|
preserve)
|
|
|
|
|
rebase=true
|
|
|
|
|
rebase_args=--preserve-merges
|
|
|
|
|
;;
|
|
|
|
|
true|false|'')
|
|
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
echo "Invalid value for --rebase, should be true, false, or preserve"
|
|
|
|
|
usage
|
|
|
|
|
exit 1
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
|
2007-12-28 22:58:43 +01:00
|
|
|
error_on_no_merge_candidates () {
|
|
|
|
|
exec >&2
|
|
|
|
|
for opt
|
|
|
|
|
do
|
|
|
|
|
case "$opt" in
|
|
|
|
|
-t|--t|--ta|--tag|--tags)
|
|
|
|
|
echo "Fetching tags only, you probably meant:"
|
|
|
|
|
echo " git fetch --tags"
|
|
|
|
|
exit 1
|
|
|
|
|
esac
|
|
|
|
|
done
|
|
|
|
|
|
2009-11-27 15:17:05 +01:00
|
|
|
if test true = "$rebase"
|
|
|
|
|
then
|
|
|
|
|
op_type=rebase
|
|
|
|
|
op_prep=against
|
|
|
|
|
else
|
|
|
|
|
op_type=merge
|
|
|
|
|
op_prep=with
|
|
|
|
|
fi
|
|
|
|
|
|
2007-12-28 22:58:43 +01:00
|
|
|
curr_branch=${curr_branch#refs/heads/}
|
2009-09-13 22:38:48 +02:00
|
|
|
upstream=$(git config "branch.$curr_branch.merge")
|
pull: improve advice for unconfigured error case
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
configuration.
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
refs/bogus/*:refs/remotes/origin/*
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-05 21:35:16 +02:00
|
|
|
remote=$(git config "branch.$curr_branch.remote")
|
2007-12-28 22:58:43 +01:00
|
|
|
|
pull: improve advice for unconfigured error case
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
configuration.
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
refs/bogus/*:refs/remotes/origin/*
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-05 21:35:16 +02:00
|
|
|
if [ $# -gt 1 ]; then
|
2009-11-27 15:17:05 +01:00
|
|
|
if [ "$rebase" = true ]; then
|
|
|
|
|
printf "There is no candidate for rebasing against "
|
|
|
|
|
else
|
|
|
|
|
printf "There are no candidates for merging "
|
|
|
|
|
fi
|
|
|
|
|
echo "among the refs that you just fetched."
|
pull: improve advice for unconfigured error case
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
configuration.
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
refs/bogus/*:refs/remotes/origin/*
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-05 21:35:16 +02:00
|
|
|
echo "Generally this means that you provided a wildcard refspec which had no"
|
|
|
|
|
echo "matches on the remote end."
|
|
|
|
|
elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
|
|
|
|
|
echo "You asked to pull from the remote '$1', but did not specify"
|
2009-11-27 15:17:05 +01:00
|
|
|
echo "a branch. Because this is not the default configured remote"
|
pull: improve advice for unconfigured error case
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
configuration.
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
refs/bogus/*:refs/remotes/origin/*
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-05 21:35:16 +02:00
|
|
|
echo "for your current branch, you must specify a branch on the command line."
|
2011-02-10 02:54:02 +01:00
|
|
|
elif [ -z "$curr_branch" -o -z "$upstream" ]; then
|
|
|
|
|
. git-parse-remote
|
|
|
|
|
error_on_missing_default_upstream "pull" $op_type $op_prep \
|
2012-03-04 05:41:26 +01:00
|
|
|
"git pull <remote> <branch>"
|
2009-09-13 22:38:48 +02:00
|
|
|
else
|
2009-11-27 15:17:05 +01:00
|
|
|
echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
|
|
|
|
|
echo "from the remote, but no such ref was fetched."
|
2009-04-08 09:24:03 +02:00
|
|
|
fi
|
2007-12-28 22:58:43 +01:00
|
|
|
exit 1
|
|
|
|
|
}
|
|
|
|
|
|
2008-01-26 19:04:37 +01:00
|
|
|
test true = "$rebase" && {
|
2009-08-12 05:27:40 +02:00
|
|
|
if ! git rev-parse -q --verify HEAD >/dev/null
|
|
|
|
|
then
|
|
|
|
|
# On an unborn branch
|
|
|
|
|
if test -f "$GIT_DIR/index"
|
|
|
|
|
then
|
2011-05-21 20:43:55 +02:00
|
|
|
die "$(gettext "updating an unborn branch with changes added to the index")"
|
2009-08-12 05:27:40 +02:00
|
|
|
fi
|
|
|
|
|
else
|
2010-10-19 16:39:28 +02:00
|
|
|
require_clean_work_tree "pull with rebase" "Please commit or stash them."
|
2009-08-12 05:27:40 +02:00
|
|
|
fi
|
2009-07-19 09:45:16 +02:00
|
|
|
oldremoteref= &&
|
2012-10-23 22:39:56 +02:00
|
|
|
test -n "$curr_branch" &&
|
2008-01-26 19:04:37 +01:00
|
|
|
. git-parse-remote &&
|
2009-07-19 09:45:16 +02:00
|
|
|
remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
|
|
|
|
|
oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
|
|
|
|
|
for reflog in $(git rev-list -g $remoteref 2>/dev/null)
|
|
|
|
|
do
|
|
|
|
|
if test "$reflog" = "$(git merge-base $reflog $curr_branch)"
|
|
|
|
|
then
|
|
|
|
|
oldremoteref="$reflog"
|
|
|
|
|
break
|
|
|
|
|
fi
|
|
|
|
|
done
|
2008-01-26 19:04:37 +01:00
|
|
|
}
|
2008-12-03 14:26:50 +01:00
|
|
|
orig_head=$(git rev-parse -q --verify HEAD)
|
2010-11-12 13:54:52 +01:00
|
|
|
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
|
2010-05-25 08:07:25 +02:00
|
|
|
test -z "$dry_run" || exit 0
|
2005-08-26 03:15:32 +02:00
|
|
|
|
2008-12-03 14:26:50 +01:00
|
|
|
curr_head=$(git rev-parse -q --verify HEAD)
|
2008-10-15 00:32:20 +02:00
|
|
|
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
|
2005-08-26 03:15:32 +02:00
|
|
|
then
|
|
|
|
|
# The fetch involved updating the current branch.
|
|
|
|
|
|
|
|
|
|
# The working tree and the index file is still based on the
|
|
|
|
|
# $orig_head commit, but we are merging into $curr_head.
|
|
|
|
|
# First update the working tree to match $curr_head.
|
|
|
|
|
|
2011-08-07 13:58:15 +02:00
|
|
|
eval_gettextln "Warning: fetch updated the current branch head.
|
2011-05-21 20:43:57 +02:00
|
|
|
Warning: fast-forwarding your working tree from
|
2011-08-07 13:58:15 +02:00
|
|
|
Warning: commit \$orig_head." >&2
|
2009-04-23 03:46:02 +02:00
|
|
|
git update-index -q --refresh
|
2007-07-03 07:52:14 +02:00
|
|
|
git read-tree -u -m "$orig_head" "$curr_head" ||
|
2011-05-21 20:43:56 +02:00
|
|
|
die "$(eval_gettext "Cannot fast-forward your working tree.
|
2006-03-22 10:57:11 +01:00
|
|
|
After making sure that you saved anything precious from
|
2011-05-21 20:43:56 +02:00
|
|
|
$ git diff \$orig_head
|
2006-03-22 10:57:11 +01:00
|
|
|
output, run
|
|
|
|
|
$ git reset --hard
|
2011-05-21 20:43:56 +02:00
|
|
|
to recover.")"
|
2006-03-22 10:57:11 +01:00
|
|
|
|
2005-08-26 03:15:32 +02:00
|
|
|
fi
|
|
|
|
|
|
2005-09-26 07:54:23 +02:00
|
|
|
merge_head=$(sed -e '/ not-for-merge /d' \
|
|
|
|
|
-e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \
|
|
|
|
|
tr '\012' ' ')
|
2005-08-20 11:57:26 +02:00
|
|
|
|
|
|
|
|
case "$merge_head" in
|
2005-08-23 06:57:59 +02:00
|
|
|
'')
|
2009-10-05 21:03:25 +02:00
|
|
|
error_on_no_merge_candidates "$@"
|
2005-08-23 06:57:59 +02:00
|
|
|
;;
|
2005-09-26 04:43:51 +02:00
|
|
|
?*' '?*)
|
2006-11-16 20:47:22 +01:00
|
|
|
if test -z "$orig_head"
|
|
|
|
|
then
|
2011-05-21 20:43:55 +02:00
|
|
|
die "$(gettext "Cannot merge multiple branches into empty head")"
|
2006-11-16 20:47:22 +01:00
|
|
|
fi
|
2009-02-18 14:44:02 +01:00
|
|
|
if test true = "$rebase"
|
|
|
|
|
then
|
2011-05-21 20:43:55 +02:00
|
|
|
die "$(gettext "Cannot rebase onto multiple branches")"
|
2009-02-18 14:44:02 +01:00
|
|
|
fi
|
2005-09-26 04:43:51 +02:00
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
|
pull: merge into unborn by fast-forwarding from empty tree
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>
2013-06-21 00:38:28 +02:00
|
|
|
# Pulling into unborn branch: a shorthand for branching off
|
|
|
|
|
# FETCH_HEAD, for lazy typers.
|
2006-11-16 20:47:22 +01:00
|
|
|
if test -z "$orig_head"
|
|
|
|
|
then
|
pull: merge into unborn by fast-forwarding from empty tree
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>
2013-06-21 00:38:28 +02:00
|
|
|
# Two-way merge: we claim the index is based on an empty tree,
|
|
|
|
|
# and try to fast-forward to HEAD. This ensures we will not
|
|
|
|
|
# lose index/worktree changes that the user already made on
|
|
|
|
|
# the unborn branch.
|
|
|
|
|
empty_tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904
|
|
|
|
|
git read-tree -m -u $empty_tree $merge_head &&
|
pull: update unborn branch tip after index
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>
2013-06-21 00:36:31 +02:00
|
|
|
git update-ref -m "initial pull" HEAD $merge_head "$curr_head"
|
2006-11-16 20:47:22 +01:00
|
|
|
exit
|
|
|
|
|
fi
|
|
|
|
|
|
pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches
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 <santi@agolina.net>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-13 03:50:50 +02:00
|
|
|
if test true = "$rebase"
|
|
|
|
|
then
|
|
|
|
|
o=$(git show-branch --merge-base $curr_branch $merge_head $oldremoteref)
|
|
|
|
|
if test "$oldremoteref" = "$o"
|
|
|
|
|
then
|
|
|
|
|
unset oldremoteref
|
|
|
|
|
fi
|
|
|
|
|
fi
|
|
|
|
|
|
2008-04-06 03:23:46 +02:00
|
|
|
merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
|
2010-01-18 07:31:38 +01:00
|
|
|
case "$rebase" in
|
|
|
|
|
true)
|
2013-08-13 05:43:42 +02:00
|
|
|
eval="git-rebase $diffstat $strategy_args $merge_args $rebase_args $verbosity"
|
2010-01-18 07:31:38 +01:00
|
|
|
eval="$eval --onto $merge_head ${oldremoteref:-$merge_head}"
|
|
|
|
|
;;
|
|
|
|
|
*)
|
2013-03-31 18:02:24 +02:00
|
|
|
eval="git-merge $diffstat $no_commit $verify_signatures $edit $squash $no_ff $ff_only"
|
2011-02-20 10:56:56 +01:00
|
|
|
eval="$eval $log_arg $strategy_args $merge_args $verbosity $progress"
|
|
|
|
|
eval="$eval \"\$merge_name\" HEAD $merge_head"
|
2010-01-18 07:31:38 +01:00
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
eval "exec $eval"
|