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* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
