star or parallele merge

[John A Meinel]

David Allouche 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.

Well, I think that Gustavo Niemeyer just submitted a patch, which lets 
"bzr log" show the merges for a given revision. Since I do believe that 
"bzr missing" uses the LogFormatter (if it doesn't, it should), then I 
think we will get the nested list by default.

So I guess the algorithm would be (in newformat):

show_missing(b_this, b_other, <extra_options>):
   a_this = set(b_this.ancestry())
   a_other = set(b_other.ancestry())
   rh_other = b_other.revision_history()

   rh_other.reverse()
   missing = []
   for rev_id in rh_other:
     if rev_id not in a_this:
       missing.append(rev_id)
     else:
       # I'm guessing we don't need to go any
       # farther, since once we have one of the
       # revisions, we should have all the history
       # Is this a true assumption?
       break

   # I like logs going forward in time, some obviously
   # prefer the opposite (since bzr log works that way)
   missing.reverse()

   lf = LogFormatter(format=format)
   for rev_id in missing:
     lf.show_log(b_other, rev_id)

That would mean that "bzr missing" should take the options --long, 
--short, --forward, --reverse (doesn't exist yet), possibly --revision 
(to only check up to a certain point), --show-ids, --quiet (just check, 
don't print anything).


> 
> I think the default should be: show only G-H-I-M with some indication
> that M is a merge. 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]).
> 

Cherry picks are not well defined in bzr. Currently, if you merge a 
revision, you just say that it is a parent of the next committed 
revision. Which implies that you have merged all of OTHER's parents.

I believe the "bzr merge" command can let you select the base, which 
effectively does a cherry pick, but doesn't set the parent, so another 
merge would try and re-apply the patches.

However, since bzr uses diff3 (Merge3), to merge, it is very likely that 
it won't conflict, as long as the area hasn't been changed.
As we switch to Weaves, in theory WeaveMerge won't conflict, as long as 
it sees that the change happened after a merge.

I'm not sure how weaves will work with cherry picked merging, but 
theoretically the newly merged lines should be marked with the OTHER 
revision.

> 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).
> 
> The option naming would be a bit delicate, because I would also like
> most commands to eventually support an option to operate on all nested
> trees. I am considering "--nested" for that, but -r, --recursive is a
> common option name for recursing into subdirectories.
> 
> My two cents.

Well, -r is already reserved for --revision, since that is used a lot. 
I'm guessing having a default of showing merged entries inside an entry 
will be okay.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051003/f4bcb118/attachment.pgp