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