GIT rebase changes

[Mike McCormack]

Hi GIT users,

The GIT guys have made rebase and pull incompatible, and to use rebase 
(which is likely what we want to do for Wine), you must use "fetch" then 
"rebase", not "pull" (which does a merge).

See:  http://article.gmane.org/gmane.linux.kernel/365410

The error message that you get if you use "pull" then try to "rebase" 
with newer version of GIT is pretty useless:

bash-3.00$ git-rebase origin
Current branch refs/heads/master is up to date.

So use "git-fetch" to update origin, then "git-rebase origin" after that 
to get the new changes.  I've update the Wiki with that information - 
don't shoot the messenger :/

Mike

[Michael Stefaniuc]

Hi!

Mike McCormack wrote:
> The GIT guys have made rebase and pull incompatible, and to use rebase 
> (which is likely what we want to do for Wine), you must use "fetch" then 
> "rebase", not "pull" (which does a merge).
> Depends if you want to keep your old history or not. "git pull" works 
> nicely.
> See:  http://article.gmane.org/gmane.linux.kernel/365410
>
> The error message that you get if you use "pull" then try to "rebase" 
> with newer version of GIT is pretty useless:
> I run into this yesterday. My master had the same code but different 
> history than origin. Did a git rebase (after branching my master so i 
> can keep my old history) and expected it to make master identical to 
> origin. I know i can achieve the same by copying the origin head over to 
> the master head but that would be like cheating.

I'm still pondering what makes more sense:
- to keep my old history, or
- rebase to origin every now and then to easier spot the differences 
between master and origin.
> bash-3.00$ git-rebase origin
> Current branch refs/heads/master is up to date.
>
> So use "git-fetch" to update origin, then "git-rebase origin" after that 
> to get the new changes.  I've update the Wiki with that information - 
> don't shoot the messenger :/

bye
	michael
-- 
Michael Stefaniuc               Tel.: [phone]
Sr. Network Engineer            Fax.: [phone]
Red Hat GmbH                    Email: mstefani(a)redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart

[Michael Stefaniuc]

I hate to reply to myself, but ...

Michael Stefaniuc wrote:
> Mike McCormack wrote:
> > The GIT guys have made rebase and pull incompatible, and to use rebase 
> > (which is likely what we want to do for Wine), you must use "fetch" 
> > then "rebase", not "pull" (which does a merge).
>
> Depends if you want to keep your old history or not. "git pull" works 
> nicely.
> > See:  http://article.gmane.org/gmane.linux.kernel/365410
> >
> > The error message that you get if you use "pull" then try to "rebase" 
> > with newer version of GIT is pretty useless:
>
> I run into this yesterday. My master had the same code but different 
> history than origin. Did a git rebase (after branching my master so i 
> can keep my old history) and expected it to make master identical to 
> origin. I know i can achieve the same by copying the origin head over to 
> the master head but that would be like cheating.
>
> I'm still pondering what makes more sense:
> - to keep my old history, or
> And this screws you up when you do git-format-patch. My VarCmp patches 
> in my master tree where composed out of a ton of separate small patches 
> (took me some time to have that function figured out) and now 
> git-format-patch dumped those out too even that my master branch and 
> origin where code wise the same. Quite annoying.
> - rebase to origin every now and then to easier spot the differences 
> between master and origin.
> Mike, you were right, "git rebase" is what we want to use. But if you do 
> not have patches sent to upstream "git pull" works too and it's faster 
> to type.

bye
	michael
-- 
Michael Stefaniuc               Tel.: [phone]
Sr. Network Engineer            Fax.: [phone]
Red Hat GmbH                    Email: mstefani(a)redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart

[Robert Shearman]

Mike McCormack wrote:
> Hi GIT users,
>
> The GIT guys have made rebase and pull incompatible, and to use rebase 
> (which is likely what we want to do for Wine), you must use "fetch" 
> then "rebase", not "pull" (which does a merge).

And on a slightly related note, I wrote a script which works kinda like 
rebase (and is based on the old version of rebase) that allows you to 
coalesce two patches in your tree. This is useful in two situations:
1. You commit a new feature and then realise after some extensive 
testing that there is a bug, so you commit a fix, don't want to send the 
two separate patches to wine-patches (maybe to save face :-), or maybe 
to reduce noise).
2. You revert a patch in your tree but don't want both the revert and 
the old patch in your patch queue as shown by git-format-patch or by 
Mike's mm-send-patch.

Note that the first commit chronologically must be the first commit on 
the command line.

-- 
Rob Shearman


#!/bin/sh
#
# Copyright (c) 2005 Junio C Hamano.
# Copyright (c) 2005 Robert Shearman.
#

. git-sh-setup || die "Not a git archive."

usage="usage: $0 "'<commit1> <commit2>

Combines two commits into one commit (commit1 MUST occur before commit2)'

git-update-index --refresh || exit

case "$#" in
2) ;;
*)
    die "$usage" ;;
esac

commit1=`git-rev-parse --verify "$1"` &&
commit1parent=`git-rev-list --max-count=2 $commit1 | tail -n1` &&
commit2=`git-rev-parse --verify "$2"` &&
ours=`git-rev-parse --verify HEAD` || exit
# FIXME: verify commit1 occurs before commit2
different1=$(git-diff-index --name-only --cached "$ours") &&
different2=$(git-diff-index --name-only "$ours") &&
test "$different1$different2" = "" ||
die "Your working tree does not match HEAD."

git-read-tree -m -u $ours $commit1parent &&
new_head=$(git-rev-parse --verify "$commit1parent^0") &&
git-update-ref HEAD "$new_head" || exit

tmp=.rebase-tmp$$
fail=$tmp-fail
trap "rm -rf $tmp-*" 1 2 3 15
> $fail

coalesce_succeeded=t
S=$(git-rev-parse --verify HEAD) &&
git-cherry-pick --no-commit --replay $commit1 || {
# shouldn't happen
	echo >&2 "* Not applying the patch and continuing."
	echo $commit1 >>$fail
	git-reset --hard $S
	coalesce_succeeded=f
}
echo "Coalescing $commit1 and $commit2" > .coalescemsg
echo "First commit:" >> .coalescemsg
echo >> .coalescemsg
cat .msg >> .coalescemsg
S=$(git-rev-parse --verify HEAD) &&
git-cherry-pick --no-commit --replay $commit2  || {
	echo >&2 "* Not applying the patch and continuing."
	echo $commit2 >>$fail
	git-reset --hard $S
	coalesce_succeeded=f
}
echo >> .coalescemsg
echo "Second commit:" >> .coalescemsg
echo >> .coalescemsg
cat .msg >> .coalescemsg

case "$coalesce_succeeded" in
t)
	git-commit --no-verify -F .coalescemsg --edit
	;;
esac
rm -f .coalescemsg


git-cherry -v $commit1parent $ours |
while read sign commit msg
do
	echo "$commit: $msg"
	case "$commit" in
	$commit1|$commit2)
		continue ;;
	esac

	case "$sign" in
	-)
		echo >&2 "* Already applied: $msg"
		continue ;;
	esac
	echo >&2 "* Applying: $msg"
	S=$(git-rev-parse --verify HEAD) &&
	git-cherry-pick --replay $commit || {
		echo >&2 "* Not applying the patch and continuing."
		echo $commit >>$fail
		git-reset --hard $S
}
done
if test -s $fail
then
	echo >&2 Some commits could not be rebased, check by hand:
	cat >&2 $fail
	echo >&2 "(the same list of commits are found in $tmp)"
	exit 1
else
	rm -f $fail
fi