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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Aug 23, 2005, 18:05 UTC
Message-ID: <Pine.LNX.4.63.0508231304130.23242@iabervon.org>
In-Reply-To: <tnxvf1wd24m.fsf@arm.com>

On Tue, 23 Aug 2005, Catalin Marinas wrote:

Show 6 quoted lines

> > So the point is that there are things which are, in fact, parents, but we
> > don't want to list them, because it's not desired information.
>
> 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?

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.

(For example, I often start with a chunk of work that does multiple things and is committed; I take mainline and generate a series of commits from there. It would be legitimate to list my development commit as a parent of each of these, since I did actually take it and strip out the unrelated changes. This would be a bit confusing in the log, but would make merges between something based on the "messy" version and something based on the "refined" version work well. On the other hand, I don't want to report the existance of the messy version, so I don't include it.)

Show 13 quoted lines

> 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.

Having a useful diff isn't really a requirement for a parent; the diff in the case of a merge is going to be the total of everything that happened elsewhere. The point is to be able to reach some commits between which there are interesting diffs.

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.

Ignoring the links to the corresponding bottoms, the development therefore looks like:

local1 -> local2 -> merge -> local3 -> merge ^ ^ ^ mainline---->-->--------->------>-->----->

And this is how development is normally supposed to look. The trick is to only include a minimal number of merges.

	-Daniel
*This .sig left intentionally blank*