another git rebase -i problem

another git rebase -i problem

[Uwe Kleine-König]

Hello,

this time it's more trivial, so maybe PEBKAC.

After applying the patch below, the test fails.  git rebase (without -i)
works.

The relevant history looks as follows:

	F - I+H+G+G - ... <- branch3
	 \
	  I

And moreover I have a more complicated history here with git rebase
failing but I think this here is not my problem :-(

Best regards
Uwe

diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index e5ed745..4d2dec7 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -362,4 +362,11 @@ test_expect_success 'rebase with a file named HEAD in worktree' '
 
 '
 
+test_expect_success 'rebase patch already merged' '
+
+	git checkout -b branch4 I &&
+	git rebase -i branch3
+
+'
+
 test_done
-- 
1.5.4.1


-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

Re: another git rebase -i problem

[Johannes Schindelin]

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

Hi,

On Thu, 14 Feb 2008, Uwe Kleine-König wrote:

> After applying the patch below, the test fails. [describes a case where 
> all patches were applied upstream already]

This is by design.  If no patches are to be applied, there is nothing you 
can do interactively.  And git rebase -i should tell you as much:

	Nothing to do

Maybe it should say

	There is nothing you can rebase interactively

But I don't like that.

Alternatively, git rebase -i could reset --hard to upstream, but I don't 
like that either: if I rebase -i, it is because I want to reorder/arrange 
patches.  If there is no patch to be rearranged, I did something wrong.

Ciao,
Dscho

Re: another git rebase -i problem

[Uwe Kleine-König]

Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 14 Feb 2008, Uwe Kleine-König wrote:
> 
> > After applying the patch below, the test fails. [describes a case where 
> > all patches were applied upstream already]
> 
> This is by design.  If no patches are to be applied, there is nothing you 
> can do interactively.  And git rebase -i should tell you as much:
> 
> 	Nothing to do
> 
> Maybe it should say
> 
> 	There is nothing you can rebase interactively
> 
> But I don't like that.
>
> Alternatively, git rebase -i could reset --hard to upstream, but I don't 
> like that either: if I rebase -i, it is because I want to reorder/arrange 
> patches.  If there is no patch to be rearranged, I did something wrong.
Ah, OK this disqualifies my test case, but the problem is real:

diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index e5ed745..f0499e6 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -362,4 +362,11 @@ test_expect_success 'rebase with a file named HEAD in worktree' '
 
 '
 
+test_expect_success 'rebase patch already merged' '
+
+	git checkout -b branch4 twerp &&
+	FAKE_LINES="1 2 4 3" git rebase -i branch3
+
+'
+
 test_done

Best regards
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

Re: another git rebase -i problem

[Johannes Schindelin]

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

Hi,

On Thu, 14 Feb 2008, Uwe Kleine-König wrote:

> Ah, OK this disqualifies my test case, but the problem is real:
> 
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index e5ed745..f0499e6 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -362,4 +362,11 @@ test_expect_success 'rebase with a file named HEAD in worktree' '
>  
>  '
>  
> +test_expect_success 'rebase patch already merged' '
> +
> +	git checkout -b branch4 twerp &&
> +	FAKE_LINES="1 2 4 3" git rebase -i branch3
> +
> +'
> +
>  test_done

Since the patches were already applied, but git (as well as you!) failed 
to remove them from the patch list, the user has to be asked to skip the 
patch.

Unfortunately, I have no time to look into this, and I do not even think 
that cherry-pick tells me if a patch was already applied (as opposed to a 
failed patch application), so I doubt that the message can be made more 
meaningful.

Anyway, your "problem" is that you have to say "git rebase --skip", 
because the patch has been applied to upstream already (but looked 
differently enough that the patch id was different).

Ciao,
Dscho

Re: another git rebase -i problem

[Uwe Kleine-König]

Hallo Johannes,

> Anyway, your "problem" is that you have to say "git rebase --skip", 
> because the patch has been applied to upstream already (but looked 
> differently enough that the patch id was different).
I just noticed that non-interactive rebase fails in that case, too.

In my eyes 

	VISUAL=: git rebase -i ...

should behave exactly as

	git rebase ...

but as this is a corner case that I will probably never run into it's OK
for me that it doesn't.

Best regards
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

Re: another git rebase -i problem

[Uwe Kleine-König]

Hello (Dscho),

> And moreover I have a more complicated history here with git rebase
> failing but I think this here is not my problem :-(
I currently have no time to have a deeper look into that either, but
here comes the more complicated case, just for the record:

	ukleinek@zentaur:~/gsrc/linux-2.6$ git rev-parse HEAD
	57db5b05c27d8c6d66264251ee1124c762aee659

	ukleinek@zentaur:~/gsrc/linux-2.6$ git rev-parse linus/master
	4ee29f6a52158cea526b16a44ae38643946103ec

	ukleinek@zentaur:~/gsrc/linux-2.6$ git status
	# On branch master
	nothing to commit (working directory clean)

	ukleinek@zentaur:~/gsrc/linux-2.6$ git rebase -i -p linus/master
	...
	(squash 57db5b0 onto d528ae7)
	...
	(write commit log for d528ae7+57db5b0)
	...
	Successfully rebased and updated refs/heads/master.

	ukleinek@zentaur:~/gsrc/linux-2.6$ git status
	# On branch master
	# Changes to be committed:
	#   (use "git reset HEAD <file>..." to unstage)
	#
	#       modified:   Documentation/00-INDEX
	#       new file:   Documentation/cpuidle/core.txt
	#       new file:   Documentation/cpuidle/driver.txt
	#       new file:   Documentation/cpuidle/governor.txt
	#       new file:   Documentation/cpuidle/sysfs.txt
	#       modified:   MAINTAINERS
	#       modified:   arch/alpha/kernel/osf_sys.c
	#       modified:   arch/arm/mach-ns9xxx/Kconfig
	#       modified:   arch/arm/mach-ns9xxx/Makefile
	#       deleted:    arch/arm/mach-ns9xxx/plat-leds-gpio.c
	#       modified:   arch/blackfin/kernel/traps.c
	#       modified:   arch/cris/arch-v10/lib/memset.c
	#       modified:   arch/cris/arch-v32/lib/memset.c
	#       modified:   arch/m68knommu/platform/5206/Makefile
	#       modified:   arch/m68knommu/platform/5206e/Makefile
	#       modified:   arch/m68knommu/platform/520x/Makefile
	#       modified:   arch/m68knommu/platform/523x/Makefile
	#       modified:   arch/m68knommu/platform/5249/Makefile
	#       modified:   arch/m68knommu/platform/5272/Makefile
	#       modified:   arch/m68knommu/platform/527x/Makefile
	#       modified:   arch/m68knommu/platform/528x/Makefile
	#       modified:   arch/m68knommu/platform/5307/Makefile
	#       modified:   arch/m68knommu/platform/532x/Makefile
	#       modified:   arch/m68knommu/platform/5407/Makefile
	#       modified:   arch/m68knommu/platform/coldfire/Makefile
	#       modified:   arch/m68knommu/platform/coldfire/entry.S
	#       modified:   arch/m68knommu/platform/coldfire/timers.c
	...

	ukleinek@zentaur:~/gsrc/linux-2.6$ git show
	commit 57db5b05c27d8c6d66264251ee1124c762aee659
	...

I tracked the problem down to NEWHEAD being wrong.  The update-ref
before warn "Successfully rebased and updated $HEADNAME." has
NEWHEAD=OLDHEAD because
.git/.dotest-merge/rewritten/57db5b05c27d8c6d66264251ee1124c762aee659
contains 57db5b05c27d8c6d66264251ee1124c762aee659 itself.

If you want to experiment with that, you can get
57db5b05c27d8c6d66264251ee1124c762aee659 from the bundle at

	http://www.modarm9.com/~ukleinek/57db5b05c2

Best regards
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962