Daniel Barkalow wrote:

> > The parents which should be visible to the outside, will always be versions
> > of my development tree, which I have previously pushed out. My way of
> > working would become:
> > * make changes, all over the place, using stgit
> > * still make changes (none of these gets tracked, intermittent versions are
> >   lost)
> > * having a good day: changes looks good, I want to push this out:
> >   * push my tree out
> >   * stgit-free (which makes the pushed out commits, the new parents of my
> >     stgit patches)
> > * restart from top
> I'm not sure how applicable to this situation stgit really is; I see stgit
> as optimized for the case of a patch set which is basically done, where
> you want to keep it applicable to the mainline as the mainline advances.

Maybe I forgot to mention this: I would also like to have my development
tree split up in a patch stack. The separate patches makes tracking the
mainline a lot easier (conflicts are a lot easier to solve)

> For your application, I'd just have a git branch full of various stuff,
> and then generate clean commits by branching mainline, diffing development
> against it, cutting the diff down to just what I want to push, and
> applying that. Then the clean patch goes into stgit.

But this would assume that once the patch goes into stgit, it won't
change except when the parent gets updated. I think we will still change
the patches quite a bit and simultanious by a couple of people.

> > [...]
> > my proposal does something like this, but a little more: not only does it
> > keep track of the link between old-top and new-top, it also keeps track of
> > the links between old-patch-in-between and new-patch-in-between.
> > (This makes sense when the top is being removed or reordered)
> I was thinking of this as being the top and bottom commits for a single
> tracked patch, not as a whole series. I think patches lower wouldn't be
> affected, and patches higher would see this as a rebase.

ah, ok, I misunderstood that part

Best regards,

PS. sorry if my responses are sometimes a bit late, I'm trying to find
more time to spend on this list ;-)

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to