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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2026, 16:02 UTC
Message-ID: <xmqqfr0vyyxm.fsf@gitster.g>
In-Reply-To: <f00673cc-afc8-4a4f-a668-e22c53b46181@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> 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.

Show 6 quoted lines

> 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 ;-).

Show 6 quoted lines

> 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.