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?

-- 
Stéphane

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Reply via email to