Re: What's cooking in git.git (Jul 2026, #12)

Phillip Wood <[email protected]> writes:

> If you raise a point and it is dismissed without a convincing 
> explanation then its fine to raise it again asking for more details so 
> that you can understand the reason behind the decision. That often leads 
> to a productive discussion and an improved design.

True.  But because "convincing" is not black and white, we need to
be careful a bit.

> That precedent is unfortunate, "--reedit-message" makes sense for the 
> "fixup" subcommand because we are reediting an existing message but 
> that's not the case with the "squash" subcommand where we're 
> constructing a new message from several commits. Given how new the 
> "fixup" subcommand is I'm tempted to add an "--edit" option and 
> deprecate "--reedit-message".

As "git history" is marked experimental, we can afford to tweak the
UI for the better ;-).

> Having thought about it a bit over the weekend I wonder if the best 
> solution when squashing is to default to looking at the commits being 
> squashed before deciding whether to open the editor or not and allow the 
> user to override that on the commandline like "git commit". If we're 
> squashing a bunch of "fixup!" and/or "amend!" commits into a single 
> target then I'm not sure its worth opening the editor...

Hmph, a base commit with an "amend!" (tells the machinery to use the
message from the "amend!" commit only, discarding the existing one)
is clear to me that there is no need for further editing, but if
there is any "fixup!" (code change, for which need for associating
log message change is unknown) or if there are multiple "amend!", I
am not so sure.  It does make it confusing, I suspect.