Re: Rollback of git commands

On Wed, 28 Nov 2007, Jon Smirl wrote:

all my patches applied
git rebase
cursing.... I immediately knew what I had done
update stg and install it
stg repair
four of my 15 patches tried to apply, I received messages that there
were all empty
most stg commands won't work, they complain that the commit references
in the stg .git/* state are not correct.

I then proceed to manually attempt repair.

This sounds like the content of the applied patches got pulled into the 
non-stgit history of the branch it's working on, sort of like a stg commit 
except that stgit didn't know you'd done it. Then cleaning everything up 
from stgit's perspective caused all of those patches to become empty, 
since they were already applied in the base.

I think fundamental issue you're having is that stgit is implementing the 
functionality of quilt using git's engine, not providing a version control 
system for patch series, which is what you really want. I've actually been 
working on a design for a git builtin for the idea that the patch series 
is your work product, and you want to version control that (additionally, 
you want to use git's engine to help with working on the series and 
represent it).

Out of curiousity, are you using stgit as an integrator (with your work 
being keeping a collection of patches produced separately up-to-date) or 
as a patch developer (with your work being producing a state containing a 
single large new feature while maintaining this change as a series of 
self-contained patches)? I've been thinking primarily about the integrator 
task, in part because I've found it easy enough to do the developer task 
without anything other than current git. (That is, "git rebase -i" seems 
to work fine for making changes to a single logical patch series, all of 
whose patches are prepared locally and aren't independantly named in some 
particular fashion; the things that aren't handled are "I need to replace 
the pull of netdev.git with a new pull of netdev.git" or "I need to 
replace '[PATCH] fix-the-frobnozzle-gadget' with 
'[PATCH v2] fix-the-frobnozzle-gadget'.)

The developer assist I'd actually like to see is: "I've got a single 
commit on top of a series of commits on top of an upstream commit; I want 
to distribute the changes made in the final commit to points in the series 
where the code that gets replaced (or context that gets inserted into) in 
the final commit gets introduced, with interactive stuff for sticking 
other hunks into particular commits or into new commits at some point in 
the series." That is, I want to do my revision of a patch series on the 
final commit of the series, and then have these changes distributed to the 
appropriate points, rather than doing work on intermediate states (unless 
what I'm fixing is stub code that gets replaced again in a later patch).

	-Daniel
*This .sig left intentionally blank*