Git development
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brian Gernhardt <benji@silverinsanity.com>, git@vger.kernel.org
Subject: Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.
Date: Mon, 28 Apr 2008 11:13:04 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.1.00.0804281112500.2949@eeepc-johanness> (raw)
In-Reply-To: <7vej8rgq62.fsf@gitster.siamese.dyndns.org>

Hi,

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.

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

  reply	other threads:[~2008-04-28 10:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-27 15:16 [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace Brian Gernhardt
2008-04-27 15:22 ` Johannes Schindelin
2008-04-27 15:32   ` Brian Gernhardt
2008-04-28  9:41     ` Jeff King
2008-04-28  9:56       ` Mike Ralphson
2008-05-13  9:11         ` Jeff King
2008-05-13 18:10           ` Mike Ralphson
2008-05-15 10:16             ` Mike Ralphson
2008-05-15 11:20               ` Jeff King
2008-05-15 11:23                 ` Jeff King
2008-05-15 17:18                 ` Junio C Hamano
2008-05-16 14:22                   ` Mike Ralphson
2008-04-28 12:40       ` Brian Gernhardt
2008-04-27 17:31   ` Junio C Hamano
2008-04-28 10:13     ` Johannes Schindelin [this message]
2008-04-28 11:40       ` Jörg Sommer
2008-04-28 13:42         ` Johannes Schindelin
2008-04-28 16:30           ` Jörg Sommer
2008-04-28 18:07             ` Johannes Schindelin
2008-04-28 16:19       ` Junio C Hamano
2008-04-28 18:01         ` Johannes Schindelin
2008-04-28 21:24           ` Junio C Hamano
2008-04-28 21:30             ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.1.00.0804281112500.2949@eeepc-johanness \
    --to=johannes.schindelin@gmx.de \
    --cc=benji@silverinsanity.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox