>>>>> James Westby <jw+deb...@jameswestby.net> writes:
<snip/>
> 3) Improved conflicts.
> I'm not sure this is really merge-upstream specific, but often people
> have difficulty understanding why a conflict happened, especially with
> this command it seems.
> I know there has been some work on improving the conflict
> experience, and I'm not sure if that has had an impact here yet.
Only a first step has landed as I went into related and semi-related
bugs about tree transform.
There is a merge proposal that goes in this direction pending review at:
https://code.edge.launchpad.net/~vila/bzr/323111-orphan-config-option/+merge/35690
(with pre-requisites).
> 4) Remembering the upstream branch.
> merge-upstream takes an optional upstream branch. Currently there are
> cases where one person supplies it, but the next doesn't, and that's not
> ideal, as you get a discontinuity, and there can be extra conflicts in
> future due to added files.
Still related to parallel imports ?
Martin mentioned recently that we could special-case merge to relax the
conflicts for different file-ids by checking the paths involved. That
would not solve the parallel import problem but it may help for the
packaging and upstream branches relationship.
> Therefore I would like if if, similar to e.g. bzr merge, if you supply a
> branch once it is remembered and used again.
That's clearly a case where some config file should be versioned and
shared even if it needs to be versioned in a specific way (the reference
to the upstream branch is a live data that doesn't flow in the same way
than the upstream code or the packaging data (or does it?)).
Would you qualify this upstream branch as a data shared by a set of
branches but for which updates are never reverted ?
> However, I don't want to have it merge a completely unrelated
> revision of some branch which you never told it to use (but
> someone else did previously.)
> Therefore I was considering the following:
> bzr merge-upstream --version 1 tarball branch
> remembers branch, and then
> bzr merge-upstream --version 2 tarball
> will re-use branch. However, it will look for a tag "2" in the branch,
> and if found that is the revision it will use. If it is not found it
> will error and demand one of -r or --no-branch.
> That way it shouldn't merge completely unrelated things.
Couldn't you use an ancestry check against the last merged revision ?
Vincent
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
