Re: git interactive rebase 'consume' command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/21/2013 12:05 PM, Michael Haggerty wrote:
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.

Yes, I agree.

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

I'm -1 on that. I value the simple format of the todo file. If I want to edit a commit, I type deif, reword - deir, fixup - deif. I'd like something equally simple like deic for this operation. There's also a 'consistency' argument there, and one I prefer to your consistency interpretation.

The same simplicity request applies to what you write below.

Thanks,

Steve.

     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


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]