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