Hi, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Sun, 27 Apr 2008, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. > 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. > Basically, the output of rebase -i -p is ugly now, because you have _two_ > ways of specifying things, > 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. > 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@xxxxxxxxxxxxxxxxxxxxxxxxxx> -- 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
