Hi, 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. 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). In that manner, every commit is identified by the (original) commit name. <irony>Surprisingly, this is the way Git was meant to operate</irony> Now, a mark command has been introduced which is totally unnecessary. Commits can _still_ be identified by their (original) commit name. That's the whole assumption rebase -i relies on. Basically, the output of rebase -i -p is ugly now, because you have _two_ ways of specifying things, and frankly, I would have to read documentation to find out when to use what. And I maintain that this was not necessary with the old way rebase -i operated. So I am really unhappy that this patch series made it in, and I am even more unhappy that my suggestions (which I made, in spite of moving between two countries, and in spite of spending a lot of time with someone very special, and therefore having less time for Git than I would have liked to) were blatantly ignored. It would have been easier for me if I would not be so utterly convinced that the "new" way is so much more complicated and unintuitive than what I suggested. And now it is already in "next", which does not help me at all (me being very busy at the moment to find a job). I am also slightly uneasy about the fact that a few obvious mistakes had to be fixed in the last days. Formulations such as "deliberately leaves $DOTEST directory behind if clean-up fails" make me wonder, too: I sincerely hope that I misunderstand the intention of this message. 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. A patch implementing a syntax like this would have won my unilateral approval (modulo expr/tac quirks, but that would have been easy to fix). Ciao, Dscho who does not like complicator's gloves -- 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
