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