From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>, Stephan Beyer <s-beyer@gmx.net>
Cc: git@vger.kernel.org,
"Stephen Haberman" <stephen@exigencecorp.com>,
spearce@spearce.org, "Thomas Rast" <trast@student.ethz.ch>,
"Björn Steinbrink" <B.Steinbrink@gmx.de>
Subject: Re: Heads up: major rebase -i -p rework coming up
Date: Sat, 24 Jan 2009 22:04:53 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.1.00.0901242156320.14855@racer> (raw)
In-Reply-To: <7vpricmoda.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 24 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > pick A
> > pick C
> > pick D
> > goto A'
> > pick B
> > merge D' was E
> >
> > This should lead to a much more intuitive user experience.
> >
> > I am very sorry if somebody actually scripted rebase -i -p (by setting
> > GIT_EDITOR with a script), but I am very certain that this cleanup is
> > absolutely necessary to make rebase -i -p useful.
>
> Three questions.
>
> - An obvious one first. How does this relate to the sequencer project
> (that seems to have gone somewhat dark?)
As far as I can see, Stephan can keep the "mark" command he cherishes so
much, and we can still use thise syntax for rebase -i -p.
> - What's with the apostrophe? I seem to remember that you argued it
> would be enough to make "A" stand for the original when it is used for
> the first time and the second and later use can stand for the result
> of the last use (e.g. the "goto A'" above can be simply spelled as
> "goto A"), when I suggested to use "mark" in a way similar to how
> fast-import language uses it during the sequencer discussion?
>
> I am not complaining; I am just being curious why the sudden change of
> heart.
Very easy explanation. I got convinced by your arguments. Even if I
could imagine that I never use the thing without apostrophe, it is good to
have an obvious indicator that this is not necessarily the original
commit.
> - Why do you need "merge D' was E"? Shouldn't "pick E" be able to
> notice that E is a merge and decompose it into "merge D' was E"
> internally?
>
> This one I am somewhat complaining, unless your answer is "because
> this way the user could drop some parents from the merge in the
> editor".
Not only that; the user could use this to fix mismerges, i.e. by replacing
a SHA-1 with the SHA-1 (or indeed, a short name, unless it is "was") of
the branch that she _actually_ wanted to merge with.
> And if your answer is that, then my next question will be "if that is
> the case, can the user be expected to easily find out which commit
> each parent SHA-1 refers to, without having more hint on the 'merge'
> insn line?"
Nope.
In most cases, however, that should be plenty enough:
merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next
The user does not have to guess much what 9383af1 might refer to.
In case of octopodes, or when the commit message was changed, the user has
to open another command line and look for herself, though.
Ciao,
Dscho
next prev parent reply other threads:[~2009-01-24 21:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-24 20:25 Heads up: major rebase -i -p rework coming up Johannes Schindelin
2009-01-24 20:37 ` Junio C Hamano
2009-01-24 21:04 ` Johannes Schindelin [this message]
2009-01-24 21:09 ` Johannes Schindelin
2009-01-24 23:01 ` Junio C Hamano
2009-01-25 2:23 ` Johannes Schindelin
2009-01-26 16:21 ` Marc Branchaud
2009-01-24 22:47 ` Thomas Rast
2009-01-25 2:05 ` Johannes Schindelin
2009-01-25 2:25 ` Johannes Schindelin
2009-01-25 13:46 ` Jakub Narebski
2009-01-25 14:17 ` Johannes Schindelin
2009-01-25 15:07 ` Sverre Rabbelier
2009-01-25 15:24 ` Johannes Schindelin
2009-01-25 20:35 ` Junio C Hamano
2009-01-25 20:59 ` Johannes Schindelin
2009-01-25 22:03 ` Jakub Narebski
2009-01-25 23:29 ` Johannes Schindelin
2009-02-03 10:05 ` Nanako Shiraishi
2009-02-03 11:47 ` Johannes Schindelin
2009-01-25 16:22 ` Jakub Narebski
2009-01-25 17:18 ` Björn Steinbrink
2009-01-26 16:10 ` Marc Branchaud
2009-01-27 15:21 ` Stephen Haberman
2009-01-27 18:08 ` Johannes Schindelin
2009-01-27 22:10 ` Nanako Shiraishi
2009-01-27 22:36 ` Stephen Haberman
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.0901242156320.14855@racer \
--to=johannes.schindelin@gmx.de \
--cc=B.Steinbrink@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=s-beyer@gmx.net \
--cc=spearce@spearce.org \
--cc=stephen@exigencecorp.com \
--cc=trast@student.ethz.ch \
/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