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

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

Catalin Marinas wrote:

> > So for example, you only tag (freeze) the history when exporting the
> > patches.  When an error is being reported on that version, it's easy to view
> > it and also view the progress that was already been made on those patches.
> 
> I agree that it is a useful feature to be able to individually tag the
> patches. The problem is how to do this best. Your approach looks to me
> like it's not following the GIT DAG structure recommendation. Maybe the
> GIT designers could further comment on this but a commit object with
> multiple parents should be a result of a merge operation. A commit with
> a single parent should represent a transition of the tree from one state
> to another. With the freeze command you proposed, a commit with multiple
> parents is no longer a result of a merge operation, but just a
> convenience for tracking the patch history with gitk.

My interpretation of parents is broader than only merges, and reading the
README file, I believe it also the intension to do so (snippet from README
file):

A "commit" object ties such directory hierarchies together into
a DAG of revisions - each "commit" is associated with exactly one tree
(the directory hierarchy at the time of the commit). In addition, a
"commit" refers to one or more "parent" commit objects that describe the
history of how we arrived at that directory hierarchy.


Another advantage of this approach is when pushing the top of your
repository to others, less rebasing would be noticed:
When pushing the top of your stack out to others, the new one won't be a
(possibly indirect) child of the previous push. This makes updating such a
head more dificult. With this approach, the new head will be a (possibly
indirect) child of the previous one (except when the top patch has been
removed, but this corner case could also be solved).

Because of this less rebasing, this aproach also facilitates co-development
on stgit patch stacks: by using a base:top id pair, the stgit patch stack
could be initialized, including its exported history. By following the
parent/child relations, 2 patch stacks could be compared and merged.

> 
> I tried your patch and test script but, if you try to reorder the
> patches, the DAG structure become quite hard to understand and that's
> only for a small set of frozen states.

I acknowledge this problem, but the solution for this would be to give
gitk another way of viewing such history: only the latest description of a
patch should be visible and the history should become more horizontal
(because the older descriptions wouldn't be shown, the history of those
patches could be viewed on the line with the latest description)

But changing gitk would only be usefull when this approach would be taken.

> 
> I think the best approach would be to keep a list of tags for each
> patch. They won't be browsable with gitk but the DAG structure would be
> clean. We might get another tool like gquilt to be able to show all the
> saved states of a patch.
> 
> Sorry for not including your patch but, while I agree with the general
> idea of frozen patch states, I disagree with its implementation.
> 

I understand your objections when limiting parents only to merges, but I see
them broader. So as you said: we indeed need a git designer to clear this up
for us.

Best regards,
Jan