Re: Rollback of git commands

On 11/28/07, Daniel Barkalow [off-list ref] wrote:

On Wed, 28 Nov 2007, Jon Smirl wrote:

quoted

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

I'm a patch developer. You need to change the patches continuously to
track feedback on the lkml type lists. You also have to rebase in
order to keep tracking head. Other people often work on the same
things and this triggers merges against the pending patches.

Another class of problem is that I can write code a lot faster than I
can get it into the kernel. Currently I have 14 pending PPC patches
that I'm maintaining while I try and get a core change into the i2c
subsystem. All of the other patches depend on the core i2c patch.

Of course the version of the i2c patch that finally gets accepted will
probably cause me to have to rework the whole patch stack again.

stgit is what you need for this work flow. It lets me easily rebase or
edit specific patches. It also lets me easily maintain private debug
patches that I can apply as needed.

I'd just like for stgit to become a core part of git so that is can be
made more bullet proof. I'm losing my patch stack every couple of
weeks. It's normally a "user error" but it is way to easy to make
these user errors.

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*

-- 
Jon Smirl
jonsmirl@gmail.com