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örg Sommer wrote: > 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. I know exactly how it works. D'oh. > You had to jump in before pick_one does anything which clearly shows you > did something different from the default way. That is bullshit. I did not do anything "different from the default way". I carefully designed an interface that was easy to understand, because it mimicked how you would do the same _by hand_, but without the hassle to actually having to do everything by hand. In other words, rebase -i is just a cherry-pick in a loop. And _exactly_ the same should have been done for -p. Namely, _not_ introduce some artificial marks, but use the _commit names_! > > 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 You carefully ignored how I intended the parents to be used: only for merges. > > 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. You know, I find it strange how you try to make a _point_ in misunderstanding me. Did I not mention that the way to have _two_ ways to reference commits was ugly? You did not even bother to remove that part from what you quoted. > > 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. Well, you carefully ignored (but removed from the quoted text) my explanation. Nevertheless, I did participate in the discussion, and mentioned my preferred way of doing things. Sheesh, Dscho
