Improving merge-upstream

[Vincent Ladeuil]

>>>>> James Westby <jw+debian at 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