Re: [RFC] Stgit - patch history / add extra parents

[Jan Veldeman <jan.veldeman@gmail.com>]

Daniel Barkalow wrote:

> On Tue, 23 Aug 2005, Catalin Marinas wrote:
> 
> Something is legitimate as a parent if someone took that commit and did
> something to it to get the new commit. The operation which caused the
> change is not specified. But you only want to include it if anyone cares
> about the parent.

This is indeed what I thought a parent should be used for. As an adition,
I'll try to explain why I would sometimes want to care about some parents:

I want to track a mailine tree, but have quite a few changes, which shoudn't
be commited to the mainline immediately (let's call it my development tree).
This is why I would use stgit. But I would also want to colaborate with
other developers on this development tree, so I sometimes want to make
updates available of this development tree to the others. This is where
current stgit falls short. To easily share this development tree, I want
some history (not all, only the ones I choose) of this development tree
included, so that the other developers can easily follow my development.

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

[...]
> This also depends on how exactly freeze is used; if you use it before
> commiting a modification to the patch without rebasing, you get:
> 
> old-top -> new-top
>       ^    ^
>        \  /
>       bottom
> 
> bottom to old-top is the old patch
> bottom to new-top is the new patch
> old-top to new-top is the change to the patch
> 
> Then you want to keep new-top as a parent for rebasings until one of these
> is frozen. These links are not interesting to look at, but preserve the
> path to the old-top:new-top change, which is interesting.

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 hope this kind of clarifies my intension.


Thank you for clarifying the meaning of parents.

Best regards,
Jan