On Wed, Oct 1, 2008 at 3:32 PM, Stéphane Glondu <[EMAIL PROTECTED]> wrote:
> 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?

If the revision graph is identical in both cases, I don't think
there's any automated way to distinguish between them.

I have to admit I don't understand why would you want to have a
situation like in your second case. If you want your build branch to
based on upstream-B but have a feature branch which has been merged
with a later upstream version, then you will get a feature patch which
contains both new upstream changes and the changes specific to the
feature branch.

I think it would be safe to assume (at least in the case of packaging)
that all the (top-) bases in a given package version are nodes in a
subgraph which starts from a single commit in the upstream branch and
where paths from this upstream commit to a given base commit contain
only other (top-)bases. I.e. .topdeps should only contain "upstream"
and other tg branches, and all the tg branches should be up to date.
Or would there be a reason to include more than one upstream commit in
the set of dependencies?


vcs-pkg-discuss mailing list

Reply via email to