1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-09 02:33:11 +01:00
git/git-pull.sh

282 lines
7.3 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2005 Junio C Hamano
#
# Fetch one or more remote refs and merge it/them into the current HEAD.
USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-s strategy]... [<fetch-options>] <repo> <head>...'
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
. git-sh-setup
set_reflog_action "pull${1+ $*}"
require_work_tree
cd_to_toplevel
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
die "Pull 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, or use 'git commit -a'."
else
die "Pull is not possible because you have unmerged files."
fi
}
die_merge () {
if [ $(git config --bool --get advice.resolveConflict || echo true) = "true" ]; then
die "You have not concluded your merge (MERGE_HEAD exists).
Please, commit your changes before you can merge."
else
die "You have not concluded your merge (MERGE_HEAD exists)."
fi
}
test -z "$(git ls-files -u)" || die_conflict
test -f "$GIT_DIR/MERGE_HEAD" && die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity= progress= recurse_submodules=
merge_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short="${curr_branch#refs/heads/}"
rebase=$(git config --bool branch.$curr_branch_short.rebase)
dry_run=
while :
do
case "$1" in
-q|--quiet)
verbosity="$verbosity -q" ;;
-v|--verbose)
verbosity="$verbosity -v" ;;
--progress)
progress=--progress ;;
--no-progress)
progress=--no-progress ;;
-n|--no-stat|--no-summary)
diffstat=--no-stat ;;
--stat|--summary)
diffstat=--stat ;;
--log|--no-log)
log_arg=$1 ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=--no-commit ;;
--c|--co|--com|--comm|--commi|--commit)
no_commit=--commit ;;
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 ;;
--no-sq|--no-squ|--no-squa|--no-squas|--no-squash)
squash=--no-squash ;;
--ff)
no_ff=--ff ;;
--no-ff)
no_ff=--no-ff ;;
--ff-only)
ff_only=--ff-only ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
case "$#,$1" in
*,*=*)
strategy=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
1,*)
usage ;;
*)
strategy="$2"
shift ;;
esac
strategy_args="${strategy_args}-s $strategy "
;;
-X*)
case "$#,$1" in
1,-X)
usage ;;
*,-X)
xx="-X $(git rev-parse --sq-quote "$2")"
shift ;;
*,*)
xx=$(git rev-parse --sq-quote "$1") ;;
esac
merge_args="$merge_args$xx "
;;
-r|--r|--re|--reb|--reba|--rebas|--rebase)
rebase=true
;;
--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
rebase=false
;;
--recurse-submodules)
recurse_submodules=--recurse-submodules
;;
--recurse-submodules=*)
recurse_submodules="$1"
;;
--no-recurse-submodules)
recurse_submodules=--no-recurse-submodules
;;
--d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
dry_run=--dry-run
;;
-h|--h|--he|--hel|--help|--help-|--help-a|--help-al|--help-all)
usage
;;
*)
# Pass thru anything that may be meant for fetch.
break
;;
esac
shift
done
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
if test true = "$rebase"
then
op_type=rebase
op_prep=against
else
op_type=merge
op_prep=with
fi
curr_branch=${curr_branch#refs/heads/}
upstream=$(git config "branch.$curr_branch.merge")
remote=$(git config "branch.$curr_branch.remote")
if [ $# -gt 1 ]; then
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."
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"
echo "a branch. Because this is not the default configured remote"
echo "for your current branch, you must specify a branch on the command line."
elif [ -z "$curr_branch" -o -z "$upstream" ]; then
. git-parse-remote
error_on_missing_default_upstream "pull" $op_type $op_prep \
"git pull <repository> <refspec>"
else
echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
echo "from the remote, but no such ref was fetched."
fi
exit 1
}
test true = "$rebase" && {
if ! git rev-parse -q --verify HEAD >/dev/null
then
# On an unborn branch
if test -f "$GIT_DIR/index"
then
die "updating an unborn branch with changes added to the index"
fi
else
require_clean_work_tree "pull with rebase" "Please commit or stash them."
fi
oldremoteref= &&
. git-parse-remote &&
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
}
orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
test -z "$dry_run" || exit 0
curr_head=$(git rev-parse -q --verify HEAD)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
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.
echo >&2 "Warning: fetch updated the current branch head."
echo >&2 "Warning: fast-forwarding your working tree from"
echo >&2 "Warning: commit $orig_head."
git update-index -q --refresh
git read-tree -u -m "$orig_head" "$curr_head" ||
die 'Cannot fast-forward your working tree.
After making sure that you saved anything precious from
$ git diff '$orig_head'
output, run
$ git reset --hard
to recover.'
fi
merge_head=$(sed -e '/ not-for-merge /d' \
-e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \
tr '\012' ' ')
case "$merge_head" in
'')
error_on_no_merge_candidates "$@"
;;
?*' '?*)
if test -z "$orig_head"
then
die "Cannot merge multiple branches into empty head"
fi
if test true = "$rebase"
then
die "Cannot rebase onto multiple branches"
fi
;;
esac
if test -z "$orig_head"
then
git update-ref -m "initial pull" HEAD $merge_head "$curr_head" &&
git read-tree -m -u HEAD || exit 1
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
merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
case "$rebase" in
true)
eval="git-rebase $diffstat $strategy_args $merge_args"
eval="$eval --onto $merge_head ${oldremoteref:-$merge_head}"
;;
*)
eval="git-merge $diffstat $no_commit $squash $no_ff $ff_only"
eval="$eval $log_arg $strategy_args $merge_args $verbosity $progress"
eval="$eval \"\$merge_name\" HEAD $merge_head"
;;
esac
eval "exec $eval"