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
next prev parent 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