recreating historic packages

[Manoj Srivastava]

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 <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C