git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3] git-rebase.txt: rewrite docu for fixup/squash (again)

From
Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date
Oct 27, 2023, 16:12 UTC
Message-ID
<ZTvhYSMOiaNbpTZ2@ugly>
In-Reply-To
<56e3e974-a027-439f-871d-c7fbae65a04e@xiplink.com>
On Fri, Oct 27, 2023 at 09:14:42AM -0400, Marc Branchaud wrote:
Show 12 quoted lines
>On 2023-10-25 06:29, Oswald Buddenhagen wrote:
>> The behavior in the presence of multiple "fixup -c" is somewhat
>> questionable, as arguably it would be better to complain about it rather
>> than letting the last instance win. But for the time being we document
>> the status quo, with a note that it is not guaranteed. Note that
>> actually changing it would require --autosquash eliding the superseded
>> uses.
>
>I do not think this kind of editorializing belongs in the commit's 
>message, but this likely isn't the first commit message that expresses 
>an opinion.
>

commmit messages should elaborate alternatives considered, which includes ones which depend on changes that can be reasonably expected to possibly happen at some point.

Show 12 quoted lines
>But I think you should remove the "but this should not be relied upon" 
>phrase.  This reads as if Git's current behaviour is undefined, which 
>most definitely is not true.
>
>Even changing this to something like "but this might change in the 
>future" is unhelpful.  Everything in Git is subject to change over a 
>long-enough time span, so the same could be said about every aspect of Git.
>
>Until the behaviour actually changes, it's perfectly fine for people to 
>use multiple "fixup -c" commands.  There's no reason to scare them off 
>of it.
>

things can't change overnight; the resistance even the most trivial behavior changes meet is enormous. so explicitly documenting long in advance that something is subject to change is basically the only way to get it changed at all.

specifically for this feature, there is no reason at all to rely on this behavior when hand-editing the todo list, and occurrences most likely indicate a mistake, which is why i would prefer it to be rejected.

regards
Previous: Marc BranchaudNext: Junio C Hamano
Message 14 of 17 in “[RESEND v2] git-rebase.txt: rewrite docu for fixup/squash (again)”
  1. Oswald BuddenhagenOct 23, 2023
  2. Phillip WoodOct 23, 2023
  3. Oswald BuddenhagenOct 23, 2023
  4. Phillip WoodOct 24, 2023
  5. Junio C HamanoOct 24, 2023
  6. Taylor BlauOct 23, 2023
  7. Oswald BuddenhagenOct 24, 2023
  8. Marc BranchaudOct 24, 2023
  9. Oswald BuddenhagenOct 24, 2023
  10. Marc BranchaudOct 27, 2023
  11. Oswald BuddenhagenOct 27, 2023
  12. git-rebase.txt: rewrite docu for fixup/squash (again)Oswald Buddenhagen, Oct 25, 2023
  13. Marc BranchaudOct 27, 2023
  14. Oswald BuddenhagenOct 27, 2023
  15. Junio C HamanoOct 27, 2023
  16. Marc BranchaudOct 31, 2023
  17. Phillip WoodOct 30, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.