|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2005 Junio C Hamano.
|
|
|
|
#
|
|
|
|
|
|
|
|
USAGE='[--onto <newbase>] <upstream> [<branch>]'
|
|
|
|
LONG_USAGE='git-rebase replaces <branch> with a new branch of the
|
|
|
|
same name. When the --onto option is provided the new branch starts
|
|
|
|
out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
|
|
|
|
It then attempts to create a new commit for each commit from the original
|
|
|
|
<branch> that does not exist in the <upstream> branch.
|
|
|
|
|
|
|
|
It is possible that a merge failure will prevent this process from being
|
|
|
|
completely automatic. You will have to resolve any such merge failure
|
|
|
|
and run git rebase --continue. Another option is to bypass the commit
|
|
|
|
that caused the merge failure with git rebase --skip. To restore the
|
|
|
|
original <branch> and remove the .dotest working files, use the command
|
|
|
|
git rebase --abort instead.
|
|
|
|
|
|
|
|
Note that if <branch> is not specified on the command line, the
|
|
|
|
currently checked out branch is used. You must be in the top
|
|
|
|
directory of your project to start (or continue) a rebase.
|
|
|
|
|
|
|
|
Example: git-rebase master~1 topic
|
|
|
|
|
|
|
|
A---B---C topic A'\''--B'\''--C'\'' topic
|
|
|
|
/ --> /
|
|
|
|
D---E---F---G master D---E---F---G master
|
|
|
|
'
|
|
|
|
. git-sh-setup
|
|
|
|
|
|
|
|
RESOLVEMSG="
|
|
|
|
When you have resolved this problem run \"git rebase --continue\".
|
|
|
|
If you would prefer to skip this patch, instead run \"git rebase --skip\".
|
|
|
|
To restore the original branch and stop rebasing run \"git rebase --abort\".
|
|
|
|
"
|
|
|
|
unset newbase
|
Status update on merge-recursive in C
This is just an update for people being interested. Alex and me were
busy with that project for a few days now. While it has progressed nicely,
there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
For impatient people: yes, it passes all the tests, and yes, according
to the evil test Alex did, it is faster than the Python script.
But no, it is not yet finished. Biggest points are:
- there are still three external calls
- in the end, it should not be necessary to write the index more than once
(just before exiting)
- a lot of things can be refactored to make the code easier and shorter
BTW we cannot just plug in git-merge-tree yet, because git-merge-tree
does not handle renames at all.
This patch is meant for testing, and as such,
- it compile the program to git-merge-recur
- it adjusts the scripts and tests to use git-merge-recur instead of
git-merge-recursive
- it provides "TEST", a script to execute the tests regarding -recursive
- it inlines the changes to read-cache.c (read_cache_from(), discard_cache()
and refresh_cache_entry())
Brought to you by Alex Riesen and Dscho
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
strategy=recur
|
|
|
|
do_merge=
|
|
|
|
dotest=$GIT_DIR/.dotest-merge
|
|
|
|
prec=4
|
|
|
|
|
|
|
|
continue_merge () {
|
|
|
|
test -n "$prev_head" || die "prev_head must be defined"
|
|
|
|
test -d "$dotest" || die "$dotest directory does not exist"
|
|
|
|
|
|
|
|
unmerged=$(git-ls-files -u)
|
|
|
|
if test -n "$unmerged"
|
|
|
|
then
|
|
|
|
echo "You still have unmerged paths in your index"
|
|
|
|
echo "did you forget update-index?"
|
|
|
|
die "$RESOLVEMSG"
|
|
|
|
fi
|
|
|
|
|
|
|
|
if test -n "`git-diff-index HEAD`"
|
|
|
|
then
|
|
|
|
if ! git-commit -C "`cat $dotest/current`"
|
|
|
|
then
|
|
|
|
echo "Commit failed, please do not call \"git commit\""
|
|
|
|
echo "directly, but instead do one of the following: "
|
|
|
|
die "$RESOLVEMSG"
|
|
|
|
fi
|
|
|
|
printf "Committed: %0${prec}d" $msgnum
|
|
|
|
else
|
|
|
|
printf "Already applied: %0${prec}d" $msgnum
|
|
|
|
fi
|
|
|
|
echo ' '`git-rev-list --pretty=oneline -1 HEAD | \
|
|
|
|
sed 's/^[a-f0-9]\+ //'`
|
|
|
|
|
|
|
|
prev_head=`git-rev-parse HEAD^0`
|
|
|
|
# save the resulting commit so we can read-tree on it later
|
|
|
|
echo "$prev_head" > "$dotest/prev_head"
|
|
|
|
|
|
|
|
# onto the next patch:
|
|
|
|
msgnum=$(($msgnum + 1))
|
|
|
|
echo "$msgnum" >"$dotest/msgnum"
|
|
|
|
}
|
|
|
|
|
|
|
|
call_merge () {
|
|
|
|
cmt="$(cat $dotest/cmt.$1)"
|
|
|
|
echo "$cmt" > "$dotest/current"
|
|
|
|
git-merge-$strategy "$cmt^" -- HEAD "$cmt"
|
|
|
|
rv=$?
|
|
|
|
case "$rv" in
|
|
|
|
0)
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
1)
|
|
|
|
test -d "$GIT_DIR/rr-cache" && git-rerere
|
|
|
|
die "$RESOLVEMSG"
|
|
|
|
;;
|
|
|
|
2)
|
|
|
|
echo "Strategy: $rv $strategy failed, try another" 1>&2
|
|
|
|
die "$RESOLVEMSG"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
die "Unknown exit code ($rv) from command:" \
|
|
|
|
"git-merge-$strategy $cmt^ -- HEAD $cmt"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
|
|
|
finish_rb_merge () {
|
|
|
|
rm -r "$dotest"
|
|
|
|
echo "All done."
|
|
|
|
}
|
|
|
|
|
|
|
|
while case "$#" in 0) break ;; esac
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
--continue)
|
|
|
|
diff=$(git-diff-files)
|
|
|
|
case "$diff" in
|
|
|
|
?*) echo "You must edit all merge conflicts and then"
|
|
|
|
echo "mark them as resolved using git update-index"
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
if test -d "$dotest"
|
|
|
|
then
|
|
|
|
prev_head="`cat $dotest/prev_head`"
|
|
|
|
end="`cat $dotest/end`"
|
|
|
|
msgnum="`cat $dotest/msgnum`"
|
|
|
|
onto="`cat $dotest/onto`"
|
|
|
|
continue_merge
|
|
|
|
while test "$msgnum" -le "$end"
|
|
|
|
do
|
|
|
|
call_merge "$msgnum"
|
|
|
|
continue_merge
|
|
|
|
done
|
|
|
|
finish_rb_merge
|
|
|
|
exit
|
|
|
|
fi
|
|
|
|
git am --resolved --3way --resolvemsg="$RESOLVEMSG"
|
|
|
|
exit
|
|
|
|
;;
|
|
|
|
--skip)
|
|
|
|
if test -d "$dotest"
|
|
|
|
then
|
|
|
|
prev_head="`cat $dotest/prev_head`"
|
|
|
|
end="`cat $dotest/end`"
|
|
|
|
msgnum="`cat $dotest/msgnum`"
|
|
|
|
msgnum=$(($msgnum + 1))
|
|
|
|
onto="`cat $dotest/onto`"
|
|
|
|
while test "$msgnum" -le "$end"
|
|
|
|
do
|
|
|
|
call_merge "$msgnum"
|
|
|
|
continue_merge
|
|
|
|
done
|
|
|
|
finish_rb_merge
|
|
|
|
exit
|
|
|
|
fi
|
|
|
|
git am -3 --skip --resolvemsg="$RESOLVEMSG"
|
|
|
|
exit
|
|
|
|
;;
|
|
|
|
--abort)
|
|
|
|
if test -d "$dotest"
|
|
|
|
then
|
|
|
|
rm -r "$dotest"
|
|
|
|
elif test -d .dotest
|
|
|
|
then
|
|
|
|
rm -r .dotest
|
|
|
|
else
|
|
|
|
die "No rebase in progress?"
|
|
|
|
fi
|
|
|
|
git reset --hard ORIG_HEAD
|
|
|
|
exit
|
|
|
|
;;
|
|
|
|
--onto)
|
|
|
|
test 2 -le "$#" || usage
|
|
|
|
newbase="$2"
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
-M|-m|--m|--me|--mer|--merg|--merge)
|
|
|
|
do_merge=t
|
|
|
|
;;
|
|
|
|
-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
|
|
|
|
do_merge=t
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
|
|
|
# Make sure we do not have .dotest
|
|
|
|
if test -z "$do_merge"
|
|
|
|
then
|
|
|
|
if mkdir .dotest
|
|
|
|
then
|
|
|
|
rmdir .dotest
|
|
|
|
else
|
|
|
|
echo >&2 '
|
|
|
|
It seems that I cannot create a .dotest directory, and I wonder if you
|
|
|
|
are in the middle of patch application or another rebase. If that is not
|
|
|
|
the case, please rm -fr .dotest and run me again. I am stopping in case
|
|
|
|
you still have something valuable there.'
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
else
|
|
|
|
if test -d "$dotest"
|
|
|
|
then
|
|
|
|
die "previous dotest directory $dotest still exists." \
|
|
|
|
'try git-rebase < --continue | --abort >'
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
Rewrite rebase to use git-format-patch piped to git-am.
The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.
Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.
Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion. You fetch
from upstream head U and find that B has been picked up. You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.
Now what?
It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand. Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.
Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.
This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge. The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.
The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:
- A series of patches in e-mail form is created that records
what A-C-D-E do, and is fed to git-am. This is stored in
.dotest/ directory, just like the case you tried to apply
them from your mailbox. Your branch is rewound to the tip of
upstream U, and the original head is kept in .git/ORIG_HEAD,
so you could "git reset --hard ORIG_HEAD" in case the end
result is really messy.
- Patch A applies cleanly. This could either be a clean patch
application on top of rewound head (i.e. same as upstream
head), or git-am might have internally fell back on 3-way
(i.e. it would have done the same thing as git-cherry-pick).
In either case, a rebased commit A is made on top of U.
- Patch C does not apply. git-am stops here, with conflicts to
be resolved in the working tree. Yet-to-be-applied D and E
are still kept in .dotest/ directory at this point. What the
user does is exactly the same as fixing up unapplicable patch
when running git-am:
- Resolve conflict just like any merge conflicts.
- "git am --resolved --3way" to continue applying the patches.
- This applies the fixed-up patch so by definition it had
better apply. "git am" knows the patch after the fixed-up
one is D and then E; it applies them, and you will get the
changes from A-C-D-E commits on top of U, in this order.
I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
# The tree must be really really clean.
|
|
|
|
git-update-index --refresh || exit
|
Rewrite rebase to use git-format-patch piped to git-am.
The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.
Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.
Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion. You fetch
from upstream head U and find that B has been picked up. You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.
Now what?
It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand. Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.
Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.
This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge. The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.
The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:
- A series of patches in e-mail form is created that records
what A-C-D-E do, and is fed to git-am. This is stored in
.dotest/ directory, just like the case you tried to apply
them from your mailbox. Your branch is rewound to the tip of
upstream U, and the original head is kept in .git/ORIG_HEAD,
so you could "git reset --hard ORIG_HEAD" in case the end
result is really messy.
- Patch A applies cleanly. This could either be a clean patch
application on top of rewound head (i.e. same as upstream
head), or git-am might have internally fell back on 3-way
(i.e. it would have done the same thing as git-cherry-pick).
In either case, a rebased commit A is made on top of U.
- Patch C does not apply. git-am stops here, with conflicts to
be resolved in the working tree. Yet-to-be-applied D and E
are still kept in .dotest/ directory at this point. What the
user does is exactly the same as fixing up unapplicable patch
when running git-am:
- Resolve conflict just like any merge conflicts.
- "git am --resolved --3way" to continue applying the patches.
- This applies the fixed-up patch so by definition it had
better apply. "git am" knows the patch after the fixed-up
one is D and then E; it applies them, and you will get the
changes from A-C-D-E commits on top of U, in this order.
I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
diff=$(git-diff-index --cached --name-status -r HEAD)
|
|
|
|
case "$diff" in
|
Rewrite rebase to use git-format-patch piped to git-am.
The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.
Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.
Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion. You fetch
from upstream head U and find that B has been picked up. You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.
Now what?
It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand. Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.
Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.
This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge. The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.
The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:
- A series of patches in e-mail form is created that records
what A-C-D-E do, and is fed to git-am. This is stored in
.dotest/ directory, just like the case you tried to apply
them from your mailbox. Your branch is rewound to the tip of
upstream U, and the original head is kept in .git/ORIG_HEAD,
so you could "git reset --hard ORIG_HEAD" in case the end
result is really messy.
- Patch A applies cleanly. This could either be a clean patch
application on top of rewound head (i.e. same as upstream
head), or git-am might have internally fell back on 3-way
(i.e. it would have done the same thing as git-cherry-pick).
In either case, a rebased commit A is made on top of U.
- Patch C does not apply. git-am stops here, with conflicts to
be resolved in the working tree. Yet-to-be-applied D and E
are still kept in .dotest/ directory at this point. What the
user does is exactly the same as fixing up unapplicable patch
when running git-am:
- Resolve conflict just like any merge conflicts.
- "git am --resolved --3way" to continue applying the patches.
- This applies the fixed-up patch so by definition it had
better apply. "git am" knows the patch after the fixed-up
one is D and then E; it applies them, and you will get the
changes from A-C-D-E commits on top of U, in this order.
I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
?*) echo "$diff"
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
# The upstream head must be given. Make sure it is valid.
|
|
|
|
upstream_name="$1"
|
|
|
|
upstream=`git rev-parse --verify "${upstream_name}^0"` ||
|
|
|
|
die "invalid upstream $upstream_name"
|
|
|
|
|
|
|
|
# If a hook exists, give it a chance to interrupt
|
|
|
|
if test -x "$GIT_DIR/hooks/pre-rebase"
|
|
|
|
then
|
|
|
|
"$GIT_DIR/hooks/pre-rebase" ${1+"$@"} || {
|
|
|
|
echo >&2 "The pre-rebase hook refused to rebase."
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
fi
|
|
|
|
|
Rewrite rebase to use git-format-patch piped to git-am.
The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.
Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.
Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion. You fetch
from upstream head U and find that B has been picked up. You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.
Now what?
It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand. Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.
Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.
This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge. The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.
The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:
- A series of patches in e-mail form is created that records
what A-C-D-E do, and is fed to git-am. This is stored in
.dotest/ directory, just like the case you tried to apply
them from your mailbox. Your branch is rewound to the tip of
upstream U, and the original head is kept in .git/ORIG_HEAD,
so you could "git reset --hard ORIG_HEAD" in case the end
result is really messy.
- Patch A applies cleanly. This could either be a clean patch
application on top of rewound head (i.e. same as upstream
head), or git-am might have internally fell back on 3-way
(i.e. it would have done the same thing as git-cherry-pick).
In either case, a rebased commit A is made on top of U.
- Patch C does not apply. git-am stops here, with conflicts to
be resolved in the working tree. Yet-to-be-applied D and E
are still kept in .dotest/ directory at this point. What the
user does is exactly the same as fixing up unapplicable patch
when running git-am:
- Resolve conflict just like any merge conflicts.
- "git am --resolved --3way" to continue applying the patches.
- This applies the fixed-up patch so by definition it had
better apply. "git am" knows the patch after the fixed-up
one is D and then E; it applies them, and you will get the
changes from A-C-D-E commits on top of U, in this order.
I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
# If the branch to rebase is given, first switch to it.
|
|
|
|
case "$#" in
|
Rewrite rebase to use git-format-patch piped to git-am.
The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.
Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.
Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion. You fetch
from upstream head U and find that B has been picked up. You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.
Now what?
It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand. Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.
Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.
This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge. The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.
The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:
- A series of patches in e-mail form is created that records
what A-C-D-E do, and is fed to git-am. This is stored in
.dotest/ directory, just like the case you tried to apply
them from your mailbox. Your branch is rewound to the tip of
upstream U, and the original head is kept in .git/ORIG_HEAD,
so you could "git reset --hard ORIG_HEAD" in case the end
result is really messy.
- Patch A applies cleanly. This could either be a clean patch
application on top of rewound head (i.e. same as upstream
head), or git-am might have internally fell back on 3-way
(i.e. it would have done the same thing as git-cherry-pick).
In either case, a rebased commit A is made on top of U.
- Patch C does not apply. git-am stops here, with conflicts to
be resolved in the working tree. Yet-to-be-applied D and E
are still kept in .dotest/ directory at this point. What the
user does is exactly the same as fixing up unapplicable patch
when running git-am:
- Resolve conflict just like any merge conflicts.
- "git am --resolved --3way" to continue applying the patches.
- This applies the fixed-up patch so by definition it had
better apply. "git am" knows the patch after the fixed-up
one is D and then E; it applies them, and you will get the
changes from A-C-D-E commits on top of U, in this order.
I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
2)
|
|
|
|
branch_name="$2"
|
|
|
|
git-checkout "$2" || usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
branch_name=`git symbolic-ref HEAD` || die "No current branch"
|
|
|
|
branch_name=`expr "z$branch_name" : 'zrefs/heads/\(.*\)'`
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
branch=$(git-rev-parse --verify "${branch_name}^0") || exit
|
|
|
|
|
|
|
|
# Make sure the branch to rebase onto is valid.
|
|
|
|
onto_name=${newbase-"$upstream_name"}
|
|
|
|
onto=$(git-rev-parse --verify "${onto_name}^0") || exit
|
|
|
|
|
|
|
|
# Now we are rebasing commits $upstream..$branch on top of $onto
|
|
|
|
|
|
|
|
# Check if we are already based on $onto, but this should be
|
|
|
|
# done only when upstream and onto are the same.
|
|
|
|
if test "$upstream" = "$onto"
|
|
|
|
then
|
|
|
|
mb=$(git-merge-base "$onto" "$branch")
|
|
|
|
if test "$mb" = "$onto"
|
|
|
|
then
|
|
|
|
echo >&2 "Current branch $branch_name is up to date."
|
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Rewind the head to "$onto"; this saves our current head in ORIG_HEAD.
|
|
|
|
git-reset --hard "$onto"
|
|
|
|
|
|
|
|
# If the $onto is a proper descendant of the tip of the branch, then
|
|
|
|
# we just fast forwarded.
|
|
|
|
if test "$mb" = "$onto"
|
|
|
|
then
|
|
|
|
echo >&2 "Fast-forwarded $branch to $newbase."
|
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
if test -z "$do_merge"
|
|
|
|
then
|
|
|
|
git-format-patch -k --stdout --full-index "$upstream"..ORIG_HEAD |
|
|
|
|
git am --binary -3 -k --resolvemsg="$RESOLVEMSG"
|
|
|
|
exit $?
|
|
|
|
fi
|
|
|
|
|
Status update on merge-recursive in C
This is just an update for people being interested. Alex and me were
busy with that project for a few days now. While it has progressed nicely,
there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
For impatient people: yes, it passes all the tests, and yes, according
to the evil test Alex did, it is faster than the Python script.
But no, it is not yet finished. Biggest points are:
- there are still three external calls
- in the end, it should not be necessary to write the index more than once
(just before exiting)
- a lot of things can be refactored to make the code easier and shorter
BTW we cannot just plug in git-merge-tree yet, because git-merge-tree
does not handle renames at all.
This patch is meant for testing, and as such,
- it compile the program to git-merge-recur
- it adjusts the scripts and tests to use git-merge-recur instead of
git-merge-recursive
- it provides "TEST", a script to execute the tests regarding -recursive
- it inlines the changes to read-cache.c (read_cache_from(), discard_cache()
and refresh_cache_entry())
Brought to you by Alex Riesen and Dscho
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
if test "@@NO_PYTHON@@" && test "$strategy" = "recur"
|
|
|
|
then
|
|
|
|
die 'The recursive merge strategy currently relies on Python,
|
|
|
|
which this installation of git was not configured with. Please consider
|
|
|
|
a different merge strategy (e.g. octopus, resolve, stupid, ours)
|
|
|
|
or install Python and git with Python support.'
|
|
|
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
# start doing a rebase with git-merge
|
|
|
|
# this is rename-aware if the recursive (default) strategy is used
|
|
|
|
|
|
|
|
mkdir -p "$dotest"
|
|
|
|
echo "$onto" > "$dotest/onto"
|
|
|
|
prev_head=`git-rev-parse HEAD^0`
|
|
|
|
echo "$prev_head" > "$dotest/prev_head"
|
|
|
|
|
|
|
|
msgnum=0
|
|
|
|
for cmt in `git-rev-list --no-merges "$upstream"..ORIG_HEAD \
|
|
|
|
| @@PERL@@ -e 'print reverse <>'`
|
|
|
|
do
|
|
|
|
msgnum=$(($msgnum + 1))
|
|
|
|
echo "$cmt" > "$dotest/cmt.$msgnum"
|
|
|
|
done
|
|
|
|
|
|
|
|
echo 1 >"$dotest/msgnum"
|
|
|
|
echo $msgnum >"$dotest/end"
|
|
|
|
|
|
|
|
end=$msgnum
|
|
|
|
msgnum=1
|
|
|
|
|
|
|
|
while test "$msgnum" -le "$end"
|
|
|
|
do
|
|
|
|
call_merge "$msgnum"
|
|
|
|
continue_merge
|
|
|
|
done
|
|
|
|
|
|
|
|
finish_rb_merge
|