Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"

[Junio C Hamano <gitster@pobox.com>]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> I think Junio is referring to this thread:
>
>   http://thread.gmane.org/gmane.comp.version-control.git/127923/focus=121874

Yes, that was the one I had in mind, and it is a shame that we somehow
ended up not taking it, perhaps in an improved form, back then.  Even
today alone, I missed the "mark for later fixing/squashing and then rebase
at the end" feature twice at dayjob.

> I too think Michael's "fix" is a good feature, and in the 
> workflow by Shawn, he knows he is fixing up an earlier 
> commit, and he knows he doesn't want to add anything to 
> the message by the fix-up commit when he makes that commit 
> (how else would he have messages like "a", "s", or "foo").

There is a slight distinction between "Shawn's fix-up commits have garbage
message and he does not want any part of them in the final commit message"
and "Shawn is happy with the message of the original commit whose tree
these fix-up commits are meant to correct."  He may still not be entirely
happy with the original message.  Wanting to edit the commit log message,
and not wanting to use the messages from follow-up commits, are two
different things.

I would agree that it is a good idea for "rebase -i" with only "fix" and
not "squash" to skip the editing of the final message.  You manually move,
or tell your "rebase --autosquash" option to automatically move, the
follow-up commits next to the ones they are meant to correct while editing
the rebase-i insn, and you change their "pick" to "fix" (or "fixup" as
Dscho and others suggested in the earlier round you quoted) only when you
know you want to keep the message of the original commit.  Otherwise you
can change them to "squash" not to "fix", and you can edit the final log
message that way.

If Michael rolls his second round with your "--autosquash", or you do so
yourself on top of his patch, I think it _might_ be safer to mark the ones
automatically moved as "squash", and not as "fix", and have the users
explicitly change the "squash" they want to "fix" themselves.
Alternatively, you can also use two magic tokens (i.e. instead of one
"fixup!", allow people to use "squash!" and "fixup!")  and change the
action chosen for the moved commits to "squash" and "fixup" respectively.

> I don't think your objection should block *others* (like
> Shawn and Junio) who can decide when they make commits 
> from using the feature from my old patch to make it even 
> easier to clean up their topics. If *you* can't decide if 
> you want to amend or not when you make a fix-up commit, you 
> can leave your fix-up commits unmarked, run interactive 
> rebase without the --autosquash option, and use Michael's 
> 'fix' manually. People who can sometimes but not always 
> decide when they make commits can do the same when they 
> can't.
>
> Isn't it what Junio suggested by his "on top of this feature", 
> and wouldn't that make everybody happy?

The answer to the first question is "yes"---I did't understand why Dscho
objected to a feature he can choose not to use if he doesn't want to, and
I still don't (unless I was misreading your earlier patch back then and it
somehow forced all rebase-i users to decide upfront at the commit time,
but I highly doubt it).

I don't know about the second one but I am guessing it would also be
"yes".