Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 28, 2008, 10:13 UTC
Message-ID: <alpine.DEB.1.00.0804281112500.2949@eeepc-johanness>
In-Reply-To: <7vej8rgq62.fsf@gitster.siamese.dyndns.org>

Hi,

On Sun, 27 Apr 2008, Junio C Hamano wrote:

Show 6 quoted lines

> 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.

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