On 11/28/07, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > 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'.) 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@xxxxxxxxx - 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
