On Wed, Oct 01 2008, Stéphane Glondu wrote: > Teemu Ikonen wrote: >> First, find a path from tagged release commit in master to the commit >> in topgit branch patch/x preceding the commit in master where patch/x >> was last merged in. Let's call this commit Px. Next, starting from Px, >> find the commit in top-bases/patch/x preceding the last merge of >> top-bases/patch/x to patch/x and call this commit Bx. The patch can >> then be recreated from diff(Bx, Px) and .topmsg at Px. > > Imagine I maintain a topic branch in "feature" based on branch > "upstream", and my "integration" (the one you tag) branch is "build": > > ------A-----------B-------C------------- (upstream) > \ \ \ > +--D---E----F-------G---H------- (feature) > \ \ \ > -------------L---J----------------K----- (build) > > Capital letters represent commits (not all of them...). Each commit in > build is also a tag. I can see two interpretations of this history graph > in terms of topgit: > - At B and C, I've updated my feature. In tag K, the base of feature is > G and the head is H. > - I've updated my feature only at B, but for some reason yet to be > imagined, I've only merged upstream into my feature branch at point C, > and I still want to use B as upstream. In this case, the base of feature > would be F, and the head H.
> How do you plan to distinguish these two cases? The second case does not seem to be the way I would interpret it. In this case, the B..C changes would be seen to be in the feature, not upstream, where they were actually developed. I suggest that the human provide guidance if they want to use F..H as the feature branch; and automated discrimination is not required. manoj -- Adapt. Enjoy. Survive. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss