Hi,


But that wasn't the way rebase -i works. You had to jump in before
pick_one does anything which clearly shows you did something different

This approach doesn't work when you change the order of commits.
Take the commit A, B and C in this order and reorder them to A C B:
1. pick A, A^ was not rewritten, nothing changed, A stays the same
2. pick C, C^ was not rewritten, nothing changed, C stays the same
3. pick B, B^ was not rewritten, nothing changed, B stays the same

Depending on your handling of the new tip of the branch you loose C or,
as your code did, nothing changed, because you made the assumption the


I doubt this. You refused any changes to your idea and your code from the
beginning. You didn't answer questions and doesn't take part on the
discussion [1] about the new syntax.

Bye, Jörg.

[1] <7vabkoufzq.fsf@gitster.siamese.dyndns.org>
-- 
Es gibt nichts schöneres als dem Schweigen eines Dummkopfes zuzuhören.
   	       		      	  	        (Helmut Quatlinger)
--

[ message continues ]

Hi,

don't cull me from the Cc: list.  This has been mentioned on this list so 
often, it is not even funny any more.

On Mon, 28 Apr 2008, J
[ message continues ]

Hi,




I don't buy, you don't use marks (notes on paper or git tags) when you reba=
se
a branch with at least 8 commits and 2 merges.

And Junio discribed how he would do such a rebase and it included marks.

And why does this test fail? Please tell me, as you =E2=80=9Cknow exactly h=
ow it
works.=E2=80=9D

diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 9cf873f..83c2964 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -361,4 +361,10 @@ test_expect_success 'rebase with a file named HEAD in =
worktree' '
=20
 '
=20
+test_expect_success 'rebase with a file named HEAD in worktree' '
+       head=3D$(git rev-parse HEAD) &&
+       FAKE_LINES=3D"1 3 2" git rebase -i -p HEAD~3 &&
+       test $(git rev-parse HEAD) !=3D $head
+'
+
 test_done

* FAIL 25: rebase with a file named HEAD in worktree

                head=3D$(git rev-parse HEAD) &&
                FAKE_LINES=3D"1 3 2" git rebase -i -p HEAD~3 &&


Because Junio told you about it. And I don't find your suggestion in
<alpine.DEB.1.00.0804141506270.28504@racer> very readable:

| I would like it much better, if there was something like
|
| pick 5cc8f37 (init: show "Reinit" message even in ...)
| pick 18d077c (quiltimport: fix misquoting of parse...)
| merge 9876543:5cc8f37,18d077c (Merge blub)
        ^^^^^^^^^^^^^^^
| reset 5cc8f37
| ...

I don't see why you complain about the marks and suggest to use
9876543:5cc8f37,18d077c. In a short example like yours it doesn't hurd,
but put 10 line between the merge an the pick and maybe change move one
of the merged commits behind the merge.

pick 8a785dc Add tests to catch problems with un-unlinkable symlinks
pick 8d14ac9 Test: catch if trash cannot be removed
pick 29dc133 git-merge-one-file: fix longstanding stupid thinko
pick deda26b Merge branch 'jc/makefile'
pick 7f8ab8d Don't update unchanged merge entries
pick 198724a fast-import: Allow "reset" to delete a new branch without error
pick ...
[ message continues ]

Hi,

On Mon, 28 Apr 2008, J
[ message continues ]