Re: Git Feature Request (Fixdown in interactive rebase)

Mike McLean <stixmclean@googlemail.com> writes:

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.