Back from holiday. Thanks to all who replied to this thread.

On Tue, 2005-08-23 at 14:05 -0400, Daniel Barkalow wrote:
> 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.

This was my initial StGIT implementation (up to version 0.3), only that
there was no freeze command. Since I want an StGIT tree to be clean to
the outside world, I wouldn't keep multiple parents for the visible top
of a patch.

As I understand from Junio's and Linus' e-mails (on the 23rd of August),
there might be problems with merging the HEAD of an StGIT-managed tree
if the above method is accessible via HEAD.

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

A merge occurs every time a patch is rebased. Anyway, having the bottoms
in the graph (which is the main idea of StGIT) together with the old-top
(or frozen state) parents make the graph pretty complicated.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to