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

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

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Oct 24, 2023, 09:22 UTC
Message-ID
<b2b76344-11b7-4f21-8658-f18ffcca2dea@gmail.com>
In-Reply-To
<ZTayxB0Nm7AEyafp@ugly>
Hi Oswald
On 23/10/2023 18:52, Oswald Buddenhagen wrote:
Show 13 quoted lines
> On Mon, Oct 23, 2023 at 05:01:02PM +0100, Phillip Wood wrote:
>> On 23/10/2023 14:00, Oswald Buddenhagen wrote:
>>> +unless "fixup -c" is used. In the latter case, the message is obtained
>>> +only from the "fixup -c" commit (having more than one of these is
>>> +incorrect).
>>
>> This change is incorrect - it is perfectly fine to have more than one 
>> "fixup -c" command. In that case we use the message of the commit of 
>> the final "fixup -c" command.
>>
> i know that this is the case, see the previous thread (which i failed to 
> link by header, cf. 
> https://lore.kernel.org/all/20231020092707.917514-1-oswald.buddenhagen@gmx.de/T/#u ).
Ah, I see Marc has already raised this point.
Show 10 quoted lines
>> One case where there can be multiple "fixup -c" commands is  when a 
>> commit has been reworded several times via "git commit 
>> --fixup=reword:<commit>" and the user runs "git rebase --autosquash"
>>
> a cleaner solution would be recognizing the situation and not generating 
> these contradicting commands in the first place. of course that would be 
> more complexity, but it would also allow catching accidental use.
> 
> of course i can go back to documenting the status quo, but it seems kind 
> of wrong.

I agree there is an argument for improving the implementation of --autosquash but until we do I think it is counterproductive to change the documentation like this as it will cause users to wonder why "rebase --autosquash" generates a todo list that is incorrect according to the documentation.

Show 11 quoted lines
>> In the case of
>>
>> pick A
>> fixup -C B
>>
>> don't we keep the authorship from A and just use the commit message 
>> from B?
>>
> uhm. we clearly do. that means i was given incorrect advice in 
> https://lore.kernel.org/all/YjXRM5HiRizZ035p@ugly/T/#u (and so the 
> thread is still looking for a resolution) ...
I'll take a look at that thread and comment there.

I do think it is a good idea to document where the authorship of a rebased commit comes from.

Best Wishes
Phillip
Previous: Oswald BuddenhagenNext: Junio C Hamano
Message 4 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.