WANTED: patch splitting tool - waypoints

WANTED: patch splitting tool - waypoints

[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.

Regards,

Bron.

Re: WANTED: patch splitting tool - waypoints

[Matthieu Moy]

Bron Gondwana <brong@brong.net> writes:

> 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.

I guess you named it: git add -p.

> So the journey A => B becomes the journey A => W => B.

Just checkout B, then

git reset HEAD^

This will reset your _index_ to the state of A (which happens to be
HEAD^, the ancestor of HEAD). Now, you can

while !happy; do
    git add -p   # select patch hunks
    git commit   # Create an intermediate commit
done
git commit -a    # Re-create commit 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.

Then, "git stash --keep-index" between "git add -p" and "git commit",
and "git stash pop" afterwards.

> And a graphical/
> ncurses interface

then, replace "git add -p; git commit" with "git gui", which will let
you select hunks and commit from a GUI.


Note that "rebase -i" is not strictly needed here, but you can apply
the above flow within a "edit" command of "rebase -i", so it's a nice
complement.

--
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: WANTED: patch splitting tool - waypoints

[Matthieu Moy]

Bron Gondwana <brong@brong.net> writes:

> 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.

About the "never made a mistake" part, if you mistakenly add a hunk
with "git add -p", then "git reset -p" (in recent enough Git's) is
your friend.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: WANTED: patch splitting tool - waypoints

[Robin Rosenberg]

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

Re: WANTED: patch splitting tool - waypoints

[Bron Gondwana]

On Sun, May 02, 2010 at 05:20:53PM +0200, Matthieu Moy wrote:
> Bron Gondwana <brong@brong.net> writes:
> 
> > 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.
> 
> About the "never made a mistake" part, if you mistakenly add a hunk
> with "git add -p", then "git reset -p" (in recent enough Git's) is
> your friend.

Ooh, that's probably the bit that I was missing :)  Excellent.  I'll
have a play and see how the workflow feels.

Thanks,

Bron.

Re: WANTED: patch splitting tool - waypoints

[Matthieu Moy]

Bron Gondwana <brong@fastmail.fm> writes:

> On Sun, May 02, 2010 at 05:20:53PM +0200, Matthieu Moy wrote:
>
>> About the "never made a mistake" part, if you mistakenly add a hunk
>> with "git add -p", then "git reset -p" (in recent enough Git's) is
>> your friend.
>
> Ooh, that's probably the bit that I was missing :)  Excellent.  I'll
> have a play and see how the workflow feels.

There's also "git stash -p", which may trigger another smiley ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: WANTED: patch splitting tool - waypoints

[Yann Dirson]

Bron Gondwana <brong <at> brong.net> writes:
> 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".

Right, this is a use-case I also commonly have, and nowadays I
mostly use the rebase -i approach already described, combined with
the use of git-gui for easy selection.

One additional trick I sometimes use, when I have reordered/squashed/split
a couple of commits, is things like "git checkout @{1}" to catch any missing
changes I could have lost while working.

Some time ago I was using stgit extensively, and had developped
a couple of scripts to support that workflow.  You will find them
in the contrib/ directory of the stgit repo, and in the
stgit-contrib debian package.  Note that I did not use them much
lately, and they may need some tweeking to work with recent
git/stgit.

The still-relevant scripts are:
  * stg-fold-files-from: pick specific hunks from another patch up the stack
  * stg-dispatch: dispatch specific hunks into another patch down the stack