Re: WANTED: patch splitting tool - waypoints

[Robin Rosenberg <robin.rosenberg@dewire.com>]

söndagen den 2 maj 2010 13.58.42 skrev  Bron Gondwana:
> 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