Re: Git Feature Request (Fixdown in interactive rebase)

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

Mike McLean <stixmclean@googlemail.com> writes:

> Can we have a similar convenience-command that squashes, and retains
> the second commit's message? Purpose is the same as the fixup command
> - saving a bit of time and unnecessary typing during a common
> operation.

We can view "fixup" as a slight variant of "squash" that gives us
the right tree by applying the change in the second commit while
reusing the message from the first commit, and the reason why its
existence makes sense is because it often happens that users find
small mistakes in the committed content that needs "fixing up" but
the small mistakes do not change the intent of the original change
so the message does not need any "fixing up".

It also often happens that users find small mistakes in the log
message text that needs "fixing up", but there is no need to change
the committed content (iow the recorded tree object), and that is
why "reword" is a useful command to have.

You are bringing up another variant of "squash" that gives us the
right tree by applying the change in the second commit while
discarding the message from the first commit and replacing it with
the message from the second commit.  Can we justify existence of
such a mode in a similar way (like I showed above to justify why
"fixup" and "reword" make sense)?  

What is the most unclear to me is where the log message in the
second commit comes from.  Was it first copied from the first commit
and then edited?  IOW, did the user do something like this?

	$ work work work
	$ git commit -e
	... record and explain the work of the first commit
	... with sufficient detail
	$ work a bit more to fix things
	$ git commit -c HEAD
	... record and explain the work of both the first and
	... the second by copying the existing first commit's log
	... and expanding to cover what the user further did

Or did the user do something more like this, in which case the log
message of the second was written pretty much from scratch to cover
work done by both commits?

	$ work work work
	$ git commit -m snapshot
	... record but give it a meaningless and expendable log
	... message
	$ work a lot more to advance
	$ git commit -e
	... record and explain what was done on the branch as
	... a whole; the log message of this commit fully describes
	... what the both commit did

Both workflows may benefit from such a feature, but at the same
time, it is unclear how realistic they are.

If two commits did comparable amount of work with similar
complexity, it would be more realistic for them to have their own
explanation that is usable as a part of the final, squashed commit,
and that is why "squash" exists.  It just is not obvious when the
new variant would be useful.  Especially if the workflow it expects
to support is the latter kind I gave (i.e. the user delays writing
meaningful log message until the last commit in the series and then
squashes everything down to one), it smells good enough to use
"squash" and get rid of a few lines at the beginning.  So there must
be some realistic workflow that benefits from the new variant, but I
do not think of one myself.

When such an explanation is given, I may agree that such a mode is a
good thing to add, but "similar to fixup" does not look like a good
enough reason.

Thanks.