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 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
> ^ ^ ^
> 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 http://vger.kernel.org/majordomo-info.html