when git-rebase -i fails to cherry-pick

when git-rebase -i fails to cherry-pick

[Uwe Kleine-König]

Hello,

even though git-rebase -i is still young, I'm already a big fan of it.

I just want to suggest two minor things:

- If a cherry-pick fails, it tells me to resolve my conflicts, 'git add
  <paths>' and to do 'git commit -c $sha1id'.

  But it doesn't tell me, how I continue to rebase after that.

  'git rebase -i --continue' works.

- If a cherry-pick of a commit to be squashed fails, the instruction to
  do 'git commit -c $sha1id' is wrong, because then I don't get both
  message to squash.

Best regards
Uwe

-- 
Uwe Kleine-König

http://www.google.com/search?q=12+mol+in+dozen

Re: when git-rebase -i fails to cherry-pick

[Johannes Schindelin]

Hi,

On Tue, 24 Jul 2007, Uwe Kleine-K?nig wrote:

> even though git-rebase -i is still young, I'm already a big fan of it.

Nice!

> I just want to suggest two minor things:
> 
> - If a cherry-pick fails, it tells me to resolve my conflicts, 'git add
>   <paths>' and to do 'git commit -c $sha1id'.
> 
>   But it doesn't tell me, how I continue to rebase after that.
> 
>   'git rebase -i --continue' works.

Actually, even "git rebase --continue" works.  And you do not really have 
to commit, either, just updating your index is fine.  In fact, if you say 
"git reset --hard", it will skip the commit.

> - If a cherry-pick of a commit to be squashed fails, the instruction to
>   do 'git commit -c $sha1id' is wrong, because then I don't get both
>   message to squash.

Yes, it is a leftover from the bad old days, when this script was called 
edit-patch-series, and I was a rebase hater.

In the meantime, somebody on IRC explained to me how rebase works, and 
that rebase lovers were quite annoyed not to be able to just resolve the 
conflicts and "git rebase --continue".

I'd appreciate if you prepared a patch with better explanations, and also 
reviewed the man page, if it is in good shape (and does not lie about the 
current behaviour).

Thanks,
Dscho

Re: when git-rebase -i fails to cherry-pick

[Uwe Kleine-König]

Hello Johannes,

Johannes Schindelin wrote:
> > - If a cherry-pick fails, it tells me to resolve my conflicts, 'git add
> >   <paths>' and to do 'git commit -c $sha1id'.
> > 
> >   But it doesn't tell me, how I continue to rebase after that.
> > 
> >   'git rebase -i --continue' works.
> 
> Actually, even "git rebase --continue" works.  And you do not really have 
> to commit, either, just updating your index is fine.  In fact, if you say 
> "git reset --hard", it will skip the commit.
OK, thanks.

> > - If a cherry-pick of a commit to be squashed fails, the instruction to
> >   do 'git commit -c $sha1id' is wrong, because then I don't get both
> >   message to squash.
> 
> Yes, it is a leftover from the bad old days, when this script was called 
> edit-patch-series, and I was a rebase hater.
> 
> In the meantime, somebody on IRC explained to me how rebase works, and 
> that rebase lovers were quite annoyed not to be able to just resolve the 
> conflicts and "git rebase --continue".
> 
> I'd appreciate if you prepared a patch with better explanations, and also 
> reviewed the man page, if it is in good shape (and does not lie about the 
> current behaviour).
It's on my todo list, but not the top item for git.

In the mean-time I found another nuisance:

After doing:

	tmpdir=/tmp/repo
	mkdir $tmpdir
	cd $tmpdir
	git init
	for n in one two three four; do echo $n >> file; git add file;
	git commit -m $n; done
	git rebase -i HEAD~3 #squash four onto two

git rebase stops (as expected) when trying to apply four, at this stage
two is already commited.

The conflicting file looks as follows:

	one
	two
	<<<<<<< HEAD:file
	=======
	three
	four
	>>>>>>> e7fbd8f... four:file

I currently have no idea how to improve this, but I miss the information
that the commit *adds* "four" and "three" is only context.

Resolving with:

	echo one > file; echo two >> file; echo four >> file;
	git add file; git rebase --continue

and typing a new log (e.g. two + four) git rebase stops once more (again
as expected) when trying to apply three, OK, resolving the conflict is
easy (one, two, three, four), git add file, git rebase --continue.

Looking at the resulting log, I have the following:

        zeisberg@cassiopeia:/tmp/repo$ git log --pretty=oneline
	145ce01e1cf3f4cb86cd0065c0d0d5b62b399ad4 three
	cd082bca636efca17409be4d871d0971237df06c two + four
	b6b985977db45e314509d94282597c2ff8029d3d two
	15f8cbbb5a452b075b49f3dedbeaeb66668b8025 one

So the request to squash two + four was lost.

I will look at it when I'm done with git-sendemail ...

Best regards
Uwe

-- 
Uwe Kleine-König

main(){char*a="main(){char*a=%c%s%c;printf(a,34,a,34%c";printf(a,34,a,34
,10);a=",10);a=%c%s%c;printf(a,34,a,34,10);}%c";printf(a,34,a,34,10);}

[PATCH] rebase -i: fix interrupted squashing

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2701 bytes --]


When a squashing merge failed, the first commit would not be replaced,
due to "git reset --soft" being called with an unmerged index.

Noticed by Uwe Kleine-König.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Tue, 24 Jul 2007, Uwe Kleine-K?nig wrote:

	> Johannes Schindelin wrote:
	>
	> > I'd appreciate if you prepared a patch with better 
	> > explanations, and also reviewed the man page, if it is in good 
	> > shape (and does not lie about the current behaviour).
	>
	> It's on my todo list, but not the top item for git.

	Please come around to do it.

	> In the mean-time I found another nuisance:
	> 
	> [outlines the test case provided in this patch]

	It would have been a bit less work for me, if you would have used 
	t/trash/ instead of /tmp/, and provided a patch for t3404 for me 
	to work with.

	Alas, the bug was squashed in 5 minutes.  It took me 15 minutes to 
	write (and test) the test.

	What a difference order can make...

 git-rebase--interactive.sh    |    2 +-
 t/t3404-rebase-interactive.sh |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 1 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 93289c0..78ae51e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -258,8 +258,8 @@ do_next () {
 		esac
 
 		failed=f
-		pick_one -n $sha1 || failed=t
 		output git reset --soft HEAD^
+		pick_one -n $sha1 || failed=t
 		author_script=$(get_author_ident_from_commit $sha1)
 		echo "$author_script" > "$DOTEST"/author-script
 		case $failed in
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 8206436..817f614 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -221,4 +221,34 @@ test_expect_success 'multi-squash only fires up editor once' '
 	test 1 = $(git show | grep ONCE | wc -l)
 '
 
+test_expect_success 'squash works as expected' '
+	for n in one two three four
+	do
+		echo $n >> file$n &&
+		git add file$n &&
+		git commit -m $n
+	done &&
+	one=$(git rev-parse HEAD~3) &&
+	FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
+	test $one = $(git rev-parse HEAD~2)
+'
+
+test_expect_success 'interrupted squash works as expected' '
+	for n in one two three four
+	do
+		echo $n >> conflict &&
+		git add conflict &&
+		git commit -m $n
+	done &&
+	one=$(git rev-parse HEAD~3) &&
+	! FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
+	(echo one; echo two; echo four) > conflict &&
+	git add conflict &&
+	! git rebase --continue &&
+	echo resolved > conflict &&
+	git add conflict &&
+	git rebase --continue &&
+	test $one = $(git rev-parse HEAD~2)
+'
+
 test_done
-- 
1.5.3.rc2.42.gda8d

Re: [PATCH] rebase -i: fix interrupted squashing

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 458 bytes --]

Hi,

On Tue, 24 Jul 2007, Johannes Schindelin wrote:

> 
> When a squashing merge failed, the first commit would not be replaced,
> due to "git reset --soft" being called with an unmerged index.
> 
> Noticed by Uwe Kleine-König.

Unfortunately, no Ack from him.

However, I have tested it myself (even unwantedly, when working on the 
work-tree sanitising, and it bit me again; I run 
"master"+branch--new-workdir ATM).

Junio, please apply...

Ciao,
Dscho

Re: [PATCH] rebase -i: fix interrupted squashing

[Junio C Hamano]

Thanks for reminding.

I thought I read the patch, felt satisfied and already applied,
but obviously I forgot the last step.  Anything else that should
be in 1.5.3 I forgot?

BTW, I _think_ somebody between your brain and my mbox mangled
umlaut in Uwe's name.  I'll fix it up.

Re: [PATCH] rebase -i: fix interrupted squashing

[Johannes Schindelin]

Hi,

On Fri, 27 Jul 2007, Junio C Hamano wrote:

> Thanks for reminding.
> 
> I thought I read the patch, felt satisfied and already applied,
> but obviously I forgot the last step.  Anything else that should
> be in 1.5.3 I forgot?

I'll try to fix that unpack bug I talked about lately, and I'd like to get 
in a little bit saner filter-branch.  One where you can read in the 
documentation "pruning paths without --subdirectory-filter is not yet 
supported, and likewise pruning by --grep".

I guess the proper fix would be to build a rev-list command line leaving 
out all the parameters which can prune the commits that the passed refs 
point to, but that is probably a little painful, to say the least.

> BTW, I _think_ somebody between your brain and my mbox mangled
> umlaut in Uwe's name.  I'll fix it up.

Thanks.

Ciao,
Dscho