Re: [Monotone-devel] How to join identical branches?

[Markus Schiltknecht]

Hi,

I think we have an understanding, that there are different use cases, 
which both need to be considered.

Stephen Leake wrote:
> > Everyone is still free to check out an old revision and branch from
> > that or look at the files, which are no longer present in a following
> > revision. 
>
> Yes, but that's more painful than preserving the changes during the
> merge, in my use case.

I doubt that in general, when taking into account all the information 
which theoretically needs to be preserved. However, in your use case, 
where merging file contents and dropping one file is fine, that's 
certainly true and applicable.

> Ok. That's a new feature; I'm not at all clear how to add that. We
> could add a cert that says "merged node <id>"; then the hard part is
> getting all the commands related to history to use that cert.

No, node ids are local, per database. So you cannot store certs (not 
even attributes) which refer to node ids. This would require additions 
to the internal revision and roster data format, AFAICT.

> Well, I there also needs to be a --merge-drop-left if you want the
> user to choose which to drop.

I was thinking that the user can swap the revisions, and put that on the 
right, from which he wants to drop files, but well...

> But then you have to specify the right
> option for each conflict; --merge-drop-right is supposed to apply to
> _all_ conflicts at once.

Oh, yes, that's another good point.

> If we could record the fact of the nodes merging in the history, it
> would not matter which was dropped.

Yes, that's how I'm imaging it working. Especially, later merges could 
succeed.

With the above variant, if Abe and Beth do the merge simultaneously, and 
Abe decides to merge into node id 1, but Beth decides to merge into node 
id 2, guess what happens when the two sync and merge again: due to die 
die die merge, *both* files will be gone - with the changes lost 
warning, yes, but they will disappear. Because monotone cannot currently 
track that users decision properly.

> It's easy enough to rename at the moment.

You are arguing that the process of dropping a file and merge into 
another one should be automated, but find renaming easy enough? I don't 
see that much difference in those two processes. For both, you need to 
commit a revision, which can then be merged with the other head.

> And you want to specify new
> names for each conflict separately; that's complicated for a single
> command line.

Agreed.

> By "automate merge" I meant that mtn would "prompt" the GUI for help
> when it got to a conflict. But I don't think the automate stdio
> interface supports interaction like that, so I guess I really mean we
> need a way to do all the steps that "merge" currently does via
> automate stdio. That capability may already be there; I'm not sure.
>
> The first step would be "give me a list of all non-content conflicts".
> I don't see that in the automate commands yet. Adding that might
> actually be easier than adding --drop-merge-right to merge; I'll look
> into it.

I'd prefer such an approach a lot. And yes, the automate interface could 
certainly do more in that area. A "try this merge" command (which would 
return possible non-content conflicts as well as content conflicts) 
would be very nice, IMO.

Regards

Markus