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

Re: WANTED: patch splitting tool - waypoints

From
Robin Rosenberg <robin.rosenberg@dewire.com>
Date
May 2, 2010, 21:10 UTC
Message-ID
<201005022310.34169.robin.rosenberg@dewire.com>
In-Reply-To
<20100502115842.GA11607@brong.net>
söndagen den 2 maj 2010 13.58.42 skrev  Bron Gondwana:
Show 42 quoted lines
> Hi,
> 
> My toolkit is missing a tool.  I've never seen it
> or anything like it, but I can describe it - and
> hopefully someone else knows if it exists.
> 
> It's basically a combination of git rebase -i and
> git add -p.  Something that allows you to split
> either a single patch or a series of patches that
> had bad "waypoints".
> 
> You can imagine the patch as a journey from A to B.
> Only, that's a long journey, and the path between
> them is a big ugly code dump.  The commits along
> the way include various adventures down rabbit holes
> that got backed out much later without necessarily
> tidying up the history along the way.
> 
> This tool allows you to easily generate one
> intermediate state.  Repeated application generates
> multiple intermediate states until you have a nice
> tidy patch series, every step of the way bisectable.
> 
> So the journey A => B becomes the journey A => W => B.
> 
> The tool allows you to quickly choose which hunks to
> add to patch(A=>W) and which to add to patch(W=>B),
> but also lets you make edits to the intermediate state
> easily so that W will compile even if some bits of the
> patch were intermingled.
> 
> 
> Does anybody know of a tool that can do this?  Does it
> sounds like something others would use?  I'm thinking
> that you could sort of get there with a combination of
> rebase squash, git add -p and a git stash holding the
> state of 'B', but it would need to be scripted enough
> that repeated application isn't a pain.  And a graphical/
> ncurses interface like the kernel's "make menuconfig" at
> the very least would make it much easier than paging
> through piles of diff fragments and hoping you never
> made a mistake.

What I do is close to what you describe. I use rebase -i and edit commits that contain too much using git gui, i.e. I remove stuff that do not belong in that commit and ammend the commit. Then I commit that extra "junk" into a (new) commit and continue.

The next round with rebase -i I rearrange and squash things. Onviously some junk gets deleted too, though the squashing takes care of most of that work.

I have a vision for Eclipse working with the history view (would translate well to any GUI) but when is not in my calendar yet.

-- robin
Previous: Matthieu MoyNext: Yann Dirson
Message 6 of 7 in “WANTED: patch splitting tool - waypoints”
  1. Bron GondwanaMay 2, 2010
  2. Matthieu MoyMay 2, 2010
  3. Matthieu MoyMay 2, 2010
  4. Bron GondwanaMay 2, 2010
  5. Matthieu MoyMay 3, 2010
  6. Robin RosenbergMay 2, 2010
  7. Yann DirsonMay 3, 2010

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.