Jeff King wrote:
> But I thought that was the point of "squash" versus "fixup"? One
> includes the commit message, and the other does not.
>
> I do think "commit --squash" is mostly useless for that reason, and I
> suspect we could do a better job in the documentation about pushing
> people to "--fixup".
>
> But --squash _can_ be useful with other options to populate the commit
> message (e.g., "--edit", which just pre-populates the subject with the
> right "squash!" line but lets you otherwise write a normal commit
> message). If that's the workflow you're using, then I'm sympathetic to
> auto-removing just a "squash!" line, as it's automated garbage that is
> only meant as a signal for --autosquash.
It's a signal for --autosquash and it gives a visual signal to humans
of where the squashed commit came from.
--squash already implies --edit, supporting this kind of workflow.
If we could turn back time and start over, would we want something
like the following?
1. if someone leaves the squash! message as is, include it as is in
the commit message without commenting out
2. if someone edits the squash! commit message to include a body
describing what is being squashed in, include the squash! line as
part of the commented marker
3. if someone leaves the (uncommented) squash! message in after being
presented with an editor at --autosquash time, reopen the editor
with some text verifying they really meant to do that
It's rare that concatenated commit messages make sense to be used as
is, especially when trailers (sign-offs, Fixes, etc) are involved. I
suspect that (3) is more important than (2) here --- we're using the
same space in the editor for input and output, and the result is a
kind of error-prone process of getting the output right.
Since we can't turn back time, one possibility would be to make tools
like "git show --check" notice the squash! lines. Would that be
useful?
One nice thing about (2) is that it's unlikely to affect scripted use.
Thoughts?
Thanks,
Jonathan
