From: Michael Haggerty <mhagger@alum.mit.edu>
To: Stephen Kelly <steveire@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Jeff King <peff@peff.net>
Subject: Re: git interactive rebase 'consume' command
Date: Mon, 21 Jan 2013 12:05:30 +0100 [thread overview]
Message-ID: <50FD20FA.8060906@alum.mit.edu> (raw)
In-Reply-To: <kdgtir$apt$1@ger.gmane.org>
On 01/20/2013 03:05 PM, Stephen Kelly wrote:
> I find the fixup command during an interactive rebase useful.
>
> Sometimes when cleaning up a branch, I end up in a situation like this:
>
> pick 07bc3c9 Good commit.
> pick 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 Another commit.
>
>
> So, I have to reorder the commits, and change 1313a5e to 'f'. An alternative
> would be to squash 's' c2f62a3 into 1313a5e and clean up the commit message.
> The problem with that is it ends up with the wrong author time information.
I do "squash with successor then clean up commit message" all the time.
I had never worried (or even thought much) about the author time of the
resulting commit. I think I will continue not worrying about it :-)
I think it would be great to have a shorthand for this operation in "git
rebase --interactive" and I probably would have implemented it when I
added "fixup" if I had been able to think of a good name for it. Even
though I do this sort of thing less frequently than "fixup", it still
comes up often enough that a special command for it would be useful.
> So, I usually reorder and then fixup, but that can also be problematic if I
> get a conflict during the re-order (which is quite likely).
It is perverse to have to turn a well-defined and manifestly
conflict-free wish into one that has a good chance of conflicting, just
because of a limitation of the tool.
> I would prefer to be able to mark a commit as 'should be consumed', so that:
>
> pick 07bc3c9 Good commit.
> consume 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 Another commit.
>
> will result in
>
> pick 07bc3c9 Good commit.
> pick 62a3c2f Another commit.
>
> directly.
Excellent. But the name is not self-explanatory. And there is
something different about your "consume" command:
Normally, "pick" means that the commit on that line is the start of a
new commit unrelated to its predecessors. And in general, the command
on one line only affects the lines that come before it, not the lines
that come after it. Under your proposal "consume" would change the
meaning of the following line, namely by changing what its "pick" means.
It might be more consistent to require the following line to be changed
to "squash":
pick 07bc3c9 Good commit.
consume 1313a5e Commit to fixup into c2f62a3.
squash c2f62a3 Another commit.
in which case the meaning of "consume" would be something like "pick
this commit but not its commit message. There would have to be a
prohibition against generating commits with *no* commit messages, to
prevent series like [consume, pick] or [consume, fix, pick] while
allowing series like [consume, consume, squash, fix, fix].
If this is the interpretation, the name "quiet/q" might make things clearer.
Yet another approach would be to allow options on the commands. For
example,
pick 07bc3c9 Good commit.
pick --quiet 1313a5e Commit to fixup into c2f62a3.
squash c2f62a3 Another commit.
In fact if options were implemented, then "fixup" would mean the same as
"squash --quiet", "reword" could be written "pick --edit", and I'm sure
the new flexibility would make it easier to add other features (e.g.,
"pick --reset-author").
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2013-01-21 11:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-20 14:05 git interactive rebase 'consume' command Stephen Kelly
2013-01-20 14:17 ` John Keeping
2013-01-20 14:23 ` Stephen Kelly
2013-01-20 19:05 ` Junio C Hamano
2013-01-20 19:13 ` Stephen Kelly
2013-01-20 20:23 ` Junio C Hamano
2013-01-21 1:49 ` Jeff King
2013-01-21 8:40 ` Stephen Kelly
2013-01-21 11:05 ` Michael Haggerty [this message]
2013-01-21 19:05 ` Stephen Kelly
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=50FD20FA.8060906@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=steveire@gmail.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;
as well as URLs for NNTP newsgroup(s).