Hi,

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
quoted text
> On Sun, 27 Apr 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > ...  It did not help that I hated the fact that that series changed 
>> > the original design without even understanding it.
>> 
>> Care to elaborate on this point further?  I do not get it.
>
> The original implementation of -p was modeled closely after filter-branch, 
> in that it created a subdirectory (dotest/rewritten) containing the new 
> commit names for those commits that were rewritten.

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
from the default way.

quoted text
> Now, whenever a commit was picked, the parents would be looked up in 
> dotest/rewritten, and replaced with the rewritten name (or left unchanged 
> if they were not rewritten).

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
new HEAD is the rewritten old HEAD.

quoted text
> Basically, the output of rebase -i -p is ugly now, because you have _two_ 
> ways of specifying things,

quoted text
> I have the feeling that I have to repeat my point again, so that it is not 
> ignored -- again.  Maybe an example would help:
>
> -- snip --
> pick abcdefg This is the first commit to be picked
> reset cdefghij
> pick zyxwvux A commit in a side-branch
> merge recursive abcdefg
> -- snap --
>
> I am convinced that this syntax does not need much explanation.

But above you said this syntax + mark is “ugly”. Strange.

quoted text
> A patch implementing a syntax like this would have won my unilateral 
> approval

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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html