star or parallele merge

[Martin Pool]

On 03/10/05, David Allouche <david at allouche.net> wrote:
> On Sun, 2005-10-02 at 22:35 -0500, John A Meinel wrote:
> > #1 A - B - C - D - E - F
> > #  | \       \
> > #2  \  G - H - I - M
> > #    \           /
> > #3     J - K - L
> >
> > The question here, is that "cd $1; bzr missing $2"
> > should certainly show G-H-I-M, but should it show J-K-L as well?
> >
> > The current missing code would not, since it looks only at
> > revision-history, but since that doesn't work quite right after merges,
> > what do we want it to do? I'm worried that showing J-K-L could be
> > considered clutter (they weren't "produced" on this branch, and showing
> > M might be all you really want to see).
>
> In the Arch tradition, "missing" would only show G-H-I-M. In my
> experience that is what one wants most of the time.
>
> However, I have found that I occasionally wanted recursive-in-revisions
> missing, J-K-L listed a as part of M. Mostly, I found that useful when
> trying to manually resolve complicated merge situations involving mesh
> merges or cherrypicks.
>
> A flat listing including J-K-L is not really useful in my experience.
>
> I think the default should be: show only G-H-I-M with some indication
> that M is a merge.

Yes, that sounds good.

The purpose of missing is to show what can/will be merged.

In the new weave format, which should become mainline this week, you
can use get_ancestry() to speed calculation of what is missing.  It
might be easiest to get a list of all missing revisions and then work
out the nesting.

One use case is that someone looks at the list of missing revisions
and decides they want only some of them.  They should then be able to
take a revision number from the list and use that with 'merge -r' to
get only up to that point.

It'd be good if the "find missing" functionality was in a library
function rather than directly in the command so it could be reused by
GUIs.

I think the order of display for the missing command is wrong at the moment.

> Even better if that distinguishes pure merges, pure
> cherrypicks, mixed merges (with additional changes or conflict
> resolution), and mixed cherrypicks. Currently, in Arch, I'm making the
> distinction by using a convention in the log message ([merge], [pick],
> [merge conflicts], [pick conflicts]).

That's probably a good convention even if we (try to) automatically
track them.  Perhaps you could add something about your method to the
wiki?

> An option, for examples -r, --recursive could recursively show the
> missing merged revisions and, distinctively, the independently merged
> revisions in missing revisions (without recursing in those).

We could use -R, --recursive since -r is already used for --revision.

--
Martin