deferred merge

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

deferred merge

Hendrik Boom-2
Is there some easy oe-time way of asking a merge to be deferred, so
that the "merged" file has both versions in it, complete with
'<<<<<<<<' and ">>>>>>>" and ssuch to mark the conflicts?  Because
sometimes it takes a lot more analysis than is practical with the emacs
merge command.

-- hendrik


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: deferred merge

Markus Wanner-2
On 03/26/2016 04:46 AM, Hendrik Boom wrote:
> Is there some easy oe-time way of asking a merge to be deferred,

Not really, no. Like a commit, this is an atomic operation: either the
resulting revision has one (commit) or two (merge) parents. So you can
only defer the merge completely. That works pretty well and may be
reasonable. For long lived diverges, I usually give one of the branches
a specific name.

> so
> that the "merged" file has both versions in it, complete with
> '<<<<<<<<' and ">>>>>>>" and ssuch to mark the conflicts?

Well, you can always commit the file including these markers. However,
they have no special meaning for monotone and things might get messy
with further merges on that same file.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: deferred merge

Hendrik Boom-2
On Sat, Mar 26, 2016 at 10:35:14AM +0100, Markus Wanner wrote:

> On 03/26/2016 04:46 AM, Hendrik Boom wrote:
> > Is there some easy oe-time way of asking a merge to be deferred,
>
> Not really, no. Like a commit, this is an atomic operation: either the
> resulting revision has one (commit) or two (merge) parents. So you can
> only defer the merge completely. That works pretty well and may be
> reasonable. For long lived diverges, I usually give one of the branches
> a specific name.
>
> > so
> > that the "merged" file has both versions in it, complete with
> > '<<<<<<<<' and ">>>>>>>" and ssuch to mark the conflicts?
>
> Well, you can always commit the file including these markers. However,
> they have no special meaning for monotone and things might get messy
> with further merges on that same file.

Thank you.

Yes, I figured it out.  The trick is not to do any merging in the emacs
merge operation, but to click into the merge buffer and save it,
telling it yes I mean it when it protests.

Then, of course, use mmore leisurely tools to analyse the resulting
mess and commmit when all those markers are gone.

Leaving markers around for yet another merge operation would probably
invite disaster.

-- hendrik

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: deferred merge

Hendrik Boom-2
On Sat, Mar 26, 2016 at 09:44:57AM -0400, Hendrik Boom wrote:

> On Sat, Mar 26, 2016 at 10:35:14AM +0100, Markus Wanner wrote:
> > On 03/26/2016 04:46 AM, Hendrik Boom wrote:
> > > Is there some easy oe-time way of asking a merge to be deferred,
> >
> > Not really, no. Like a commit, this is an atomic operation: either the
> > resulting revision has one (commit) or two (merge) parents. So you can
> > only defer the merge completely. That works pretty well and may be
> > reasonable. For long lived diverges, I usually give one of the branches
> > a specific name.
> >
> > > so
> > > that the "merged" file has both versions in it, complete with
> > > '<<<<<<<<' and ">>>>>>>" and ssuch to mark the conflicts?
> >
> > Well, you can always commit the file including these markers. However,
> > they have no special meaning for monotone and things might get messy
> > with further merges on that same file.
>
> Thank you.
>
> Yes, I figured it out.  The trick is not to do any merging in the emacs
> merge operation, but to click into the merge buffer and save it,
> telling it yes I mean it when it protests.
>
> Then, of course, use mmore leisurely tools to analyse the resulting
> mess and commmit when all those markers are gone.
>
> Leaving markers around for yet another merge operation would probably
> invite disaster.

Actually, this new method works pretty well.  It resolves all the
conflicts that it can by itslef using the usual techniques, and leaves
me the ones that require thought.  

Normally if it goes to an emacs merge, I get to settle all of them,
even the obvious ones.

-- hendrik

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: deferred merge

Stephen Leake-3
In reply to this post by Hendrik Boom-2
Hendrik Boom <[hidden email]> writes:

> Is there some easy oe-time way of asking a merge to be deferred, so
> that the "merged" file has both versions in it, complete with
> '<<<<<<<<' and ">>>>>>>" and ssuch to mark the conflicts?  Because
> sometimes it takes a lot more analysis than is practical with the emacs
> merge command.

You can use the "conflicts" set of commands; see
http://www.monotone.ca/docs/Merge-Conflicts.html#Merge-Conflicts

They let you output a list of the conflicts that will occur during a
merge, and create files that resolve the conflicts. Then when all the
conflicts are resolved, you can do the actual merge.

I implemented those commands precisely to allow more time for conflict
resolution.


--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel