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

Re: Graphical tool to merge and reorder commits

From
Ben Knoble <ben.knoble@gmail.com>
Date
Aug 19, 2025, 12:08 UTC
Message-ID
<A6B4BDD1-844C-492A-96A9-40F09F2DBD3D@gmail.com>
In-Reply-To
<f2977c6a-b588-4e30-b7bb-dfa6d4b8b45b@rd10.de>
Show 19 quoted lines
> Le 19 août 2025 à 07:28, R. Diez <rdiez-2006@rd10.de> a écrit :
> 
> 
>> - `git rebase -i HEAD~11` (or so;-)
>> - move fixA1 and fixA2 under A and change "pick" to "fixup" for fixA1 and fixA2
>> - save and exit the editor
> 
> I actually did not want to count commits or look at hashes, I wanted to comfortably click around to see the diffs etc. while I make the decisions.
> 
> After such posts, I wish people like you had to buy their next online plane or train ticket with curl. }8-)
> 
> But let's stay on the command line. I could learn new tricks.
> 
> 
>> And done.
> 
> OK, git rebase was happy, everything is done.
> 
> And now it does not compile anymore.
Perhaps there were conflicts? Reordering patches doesn’t guarantee any semantics about the code :)
> 
> You'd want to go back to the initial commit sequence and try another approach. But now it's gone, or at least it does not come up anymore in your git-gui. Or is it really gone? Maybe I can dig up the old commit sequence if I find the right Git commands... But that is what I wanted to avoid in the first place!
Try “git reflog <branch>”: it will show you that old commit.
> So I guess I should branch beforehand, just in case. And then move the head back, and rebase the commits there. Or the like. And don't squash yet, just in case. And then squash later, after everything compiles. My keyboard is on fire.
Exactly: this is what I call “defensive Git.” The objects are immutable, so when you spoke of duplicating head to attempt upthread, the best way to do so is to write down the commit hash (e.g., by labelling it with a branch). That’s “all” you have to do to duplicate.
Then you can rebase or perform some other history rewrite, which creates a brand new set of objects. If happy, abandon the old hash (e.g., delete the branch, which notably does not immediately delete the objects). Or if not, reset to the old commit and try again.
PS Have you tried using something like “commit --fixup/squash” and “rebase --autosquash [@{upstream}]” (or possibly “@{push}”—upstream is the default)? For me that automates most of the typical reordering I would do, although again conflicts are a possibility. 
Previous: R. DiezNext: Junio C Hamano
Message 9 of 11 in “Graphical tool to merge and reorder commits”
  1. R. DiezAug 17, 2025
  2. Konstantin KhomoutovAug 18, 2025
  3. Junio C HamanoAug 18, 2025
  4. Patrick SteinhardtAug 19, 2025
  5. R. DiezAug 19, 2025
  6. Bernd PetrovitschAug 19, 2025
  7. Patrick SteinhardtAug 19, 2025
  8. R. DiezAug 19, 2025
  9. Ben KnobleAug 19, 2025
  10. Junio C HamanoAug 19, 2025
  11. Johannes SixtAug 19, 2025

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.