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

[Junio C Hamano <junkio@cox.net>]

Catalin Marinas <catalin.marinas@gmail.com> writes:

> What's the definition of a parent in GIT terms? What are the
> restriction for a commit object to be a parent? Can a parent be an
> arbitrarily chosen commit?

Yes it can.  GIT does not care if the commit ancestry does not
make sense in contents terms (i.e. you can record one tree
object in a commit object, and record another, completely
unrelated tree object in a commit object that has the first
commit object as its parent).  The "git-diff-tree" output from
comparing those two commits may not make _any_ sense at all to
the human, though, but that is not a problem for GIT to do its
work.

> That's what I've been thinking. StGIT currently only implements the
> external view.
>
> An StGIT patch is a represented by a top and bottom commit
> objects. The bottom one is the same as the parent of the top
> commit. The patch is the diff between the top's tree id and the
> bottom's tree id.
>
> Jan's proposal is to allow a freeze command to save the current top
> hash and later be used as a second parent for the newly generated
> top. The problem I see with this approach is that (even for the
> internal view you described) the newly generated top will have two
> parents, new-bottom and old-top, but only the diff between new-top and
> new-bottom is meaningful. The diff between new-top and old-top (as a
> parent-child relation) wouldn't contain anything relevant to the patch
> but all the new changes to the base of the stack.
>
> Is the above an acceptable usage of the GIT DAG structure?

Surely, as long as it stays internal as StGIT patch stacks.
Even when it is exported (i.e. you manage to have other non
StGIT managed tree to pull and merge with such a commit), the
development history _might_ look funny and complicated, but it
should not be a problem for GIT to handle.  After all, you are
doing complicated thing in the StGIT patch stacks when you pop,
push and freeze number of times, so your history is complicated.
If you want to record that history at least for StGIT internal
bookkeeping purposes, GIT should not prevent you from doing it.

Having said that, I would 100% agree with you that having a
cleansed external view would be a good idea.  It makes merging
with StGIT managed repositories much more acceptable to ordinary
GIT managed history.