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, 13:42 UTC
Message-ID: <alpine.DEB.1.00.0804281409030.5399@eeepc-johanness>
In-Reply-To: <slrng1bdsf.25r.joerg@alea.gnuu.de>

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:

Show 15 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 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.

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_!

Show 9 quoted lines

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

Show 16 quoted lines

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

Show 6 quoted lines

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