hg resolve

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

hg resolve

Leslie P. Polzer-3

Are there other people who are annoyed by "hg resolve"?

First issue: the output "abort: unresolved merge conflicts
(see hg resolve)" is quite unspecific. Should I just type
"hg resolve", look up its help, then what?

How about something like this instead:

  abort: unresolved merge conflicts.
  Use "hg resolve -l" to list the conflicting files
  followed by "hg resolve -m FILE..." to mark them as
  resolved after fixing the conflicts.

Second issue, related: resolve without any arguments will
just overwrite a fixed conflict, discarding any changes
made.

It should warn/ask the user interactively whether they
really want to do that. Alternative: no default behaviour
at all and a new switch that will restore the original
conflicts.

  Leslie

--
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Peter Arrenbrecht
On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
<[hidden email]> wrote:
> Second issue, related: resolve without any arguments will
> just overwrite a fixed conflict, discarding any changes
> made.
>
> It should warn/ask the user interactively whether they
> really want to do that. Alternative: no default behaviour
> at all and a new switch that will restore the original
> conflicts.

+1. This has bitten me more than once, too. But maybe it's too late
for removing the default (backward compat rules).
-parren
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Dirkjan Ochtman
In reply to this post by Leslie P. Polzer-3
On 10/12/2008 11:11, Leslie P. Polzer wrote:
> Are there other people who are annoyed by "hg resolve"?

Apparently, yes. I had a request today from someone who really wanted
the changesets involved to be printed, as it was before (when it showed
advice to hg update -rxxx, then hg update -ryyy). He used this to help
make his merge go smoother.

Cheers,

Dirkjan

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

TK Soh
In reply to this post by Peter Arrenbrecht
On Wed, Dec 10, 2008 at 3:54 PM, Peter Arrenbrecht
<[hidden email]> wrote:

> On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
> <[hidden email]> wrote:
>> Second issue, related: resolve without any arguments will
>> just overwrite a fixed conflict, discarding any changes
>> made.
>>
>> It should warn/ask the user interactively whether they
>> really want to do that. Alternative: no default behaviour
>> at all and a new switch that will restore the original
>> conflicts.
>
> +1. This has bitten me more than once, too. But maybe it's too late
> for removing the default (backward compat rules).

If the rules have to be broken, it's better to do it while 1.1 is still 'warm'.
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

peterloron
On Dec 10, 2008, at 4:36 PM, TK Soh wrote:

> On Wed, Dec 10, 2008 at 3:54 PM, Peter Arrenbrecht
> <[hidden email]> wrote:
>> On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
>> <[hidden email]> wrote:
>>> Second issue, related: resolve without any arguments will
>>> just overwrite a fixed conflict, discarding any changes
>>> made.
>>>
>>> It should warn/ask the user interactively whether they
>>> really want to do that. Alternative: no default behaviour
>>> at all and a new switch that will restore the original
>>> conflicts.
>>
>> +1. This has bitten me more than once, too. But maybe it's too late
>> for removing the default (backward compat rules).
>
> If the rules have to be broken, it's better to do it while 1.1 is  
> still 'warm'.

+2  This would be a very good change.
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Matt Mackall
On Fri, 2008-12-12 at 15:31 -0800, Peter Loron wrote:

> On Dec 10, 2008, at 4:36 PM, TK Soh wrote:
>
> > On Wed, Dec 10, 2008 at 3:54 PM, Peter Arrenbrecht
> > <[hidden email]> wrote:
> >> On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
> >> <[hidden email]> wrote:
> >>> Second issue, related: resolve without any arguments will
> >>> just overwrite a fixed conflict, discarding any changes
> >>> made.
> >>>
> >>> It should warn/ask the user interactively whether they
> >>> really want to do that. Alternative: no default behaviour
> >>> at all and a new switch that will restore the original
> >>> conflicts.
> >>
> >> +1. This has bitten me more than once, too. But maybe it's too late
> >> for removing the default (backward compat rules).
> >
> > If the rules have to be broken, it's better to do it while 1.1 is  
> > still 'warm'.
>
> +2  This would be a very good change.

Sorry, you only get one vote.

We plan to add a new -a switch analogous to revert's.

--
Mathematics is the supreme nostalgia of our time.

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Peter Arrenbrecht
On Thu, Dec 18, 2008 at 6:26 PM, Matt Mackall <[hidden email]> wrote:

> On Fri, 2008-12-12 at 15:31 -0800, Peter Loron wrote:
>> On Dec 10, 2008, at 4:36 PM, TK Soh wrote:
>>
>> > On Wed, Dec 10, 2008 at 3:54 PM, Peter Arrenbrecht
>> > <[hidden email]> wrote:
>> >> On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
>> >> <[hidden email]> wrote:
>> >>> Second issue, related: resolve without any arguments will
>> >>> just overwrite a fixed conflict, discarding any changes
>> >>> made.
>> >>>
>> >>> It should warn/ask the user interactively whether they
>> >>> really want to do that. Alternative: no default behaviour
>> >>> at all and a new switch that will restore the original
>> >>> conflicts.
>> >>
>> >> +1. This has bitten me more than once, too. But maybe it's too late
>> >> for removing the default (backward compat rules).
>> >
>> > If the rules have to be broken, it's better to do it while 1.1 is
>> > still 'warm'.
>>
>> +2  This would be a very good change.
>
> Sorry, you only get one vote.
>
> We plan to add a new -a switch analogous to revert's.

But no change to the default behaviour, meaning `hg resolve the/file`
will clobber any manual resolving I've already done when I meant to
say `hg resolve -m the/file`?
-parren
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

cboos
Peter Arrenbrecht wrote:

> On Thu, Dec 18, 2008 at 6:26 PM, Matt Mackall <[hidden email]> wrote:
>  
>> On Fri, 2008-12-12 at 15:31 -0800, Peter Loron wrote:
>>    
>>> On Dec 10, 2008, at 4:36 PM, TK Soh wrote:
>>>
>>>      
>>>> On Wed, Dec 10, 2008 at 3:54 PM, Peter Arrenbrecht
>>>> <[hidden email]> wrote:
>>>>        
>>>>> On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
>>>>> <[hidden email]> wrote:
>>>>>          
>>>>>> Second issue, related: resolve without any arguments will
>>>>>> just overwrite a fixed conflict, discarding any changes
>>>>>> made.
>>>>>>
>>>>>> It should warn/ask the user interactively whether they
>>>>>> really want to do that. Alternative: no default behaviour
>>>>>> at all and a new switch that will restore the original
>>>>>> conflicts.
>>>>>>            
>>>>> +1. This has bitten me more than once, too. But maybe it's too late
>>>>> for removing the default (backward compat rules).
>>>>>          
>>>> If the rules have to be broken, it's better to do it while 1.1 is
>>>> still 'warm'.
>>>>        
>>> +2  This would be a very good change.
>>>      
>> Sorry, you only get one vote.
>>
>> We plan to add a new -a switch analogous to revert's.
>>    
>
> But no change to the default behaviour, meaning `hg resolve the/file`
> will clobber any manual resolving I've already done when I meant to
> say `hg resolve -m the/file`?
>  

I would further emphasize that this is especially error prone for those
using both svn and hg. As you'd write `svn resolved` in Subversion for
marking as resolved, you are tempted to do the same in Mercurial and
forget about the '-m' option. I've added a "resolved" alias in order to
cope with this, but I fully agree that "hg resolve the/file" being
destructive is a bit dangerous.

-- Christian
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Alexander Solovyov
On 2008-12-19, Christian Boos wrote:

> cope with this, but I fully agree that "hg resolve the/file" being
> destructive is a bit dangerous.

Sure, yesterday my friend asked me why "hg resolve path/to/file" reverts
his file to pre-merged state.

He is coming from git and not used to read help ;-), but anyway IMHO
this is a problem.

--
Alexander
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Remy Blank-2
In reply to this post by cboos
Christian Boos wrote:
> but I fully agree that "hg resolve the/file" being
> destructive is a bit dangerous.

Same feeling here, without "a bit".

-- Remy


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Dirkjan Ochtman
In reply to this post by Peter Arrenbrecht
On 19/12/2008 10:07, Peter Arrenbrecht wrote:
> But no change to the default behaviour, meaning `hg resolve the/file`
> will clobber any manual resolving I've already done when I meant to
> say `hg resolve -m the/file`?

The idea is that hg resolve without -a will be equivalent to -l.

Cheers,

Dirkjan
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Peter Arrenbrecht
On Fri, Dec 19, 2008 at 9:29 PM, Dirkjan Ochtman <[hidden email]> wrote:
> On 19/12/2008 10:07, Peter Arrenbrecht wrote:
>>
>> But no change to the default behaviour, meaning `hg resolve the/file`
>> will clobber any manual resolving I've already done when I meant to
>> say `hg resolve -m the/file`?
>
> The idea is that hg resolve without -a will be equivalent to -l.

But will `hg resolve the/file` still clobber work? I rarely just say
`hg resolve`, so the -a fix is not much of a help to me.
-parren
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Matt Mackall
In reply to this post by Peter Arrenbrecht
On Fri, 2008-12-19 at 10:07 +0100, Peter Arrenbrecht wrote:

> On Thu, Dec 18, 2008 at 6:26 PM, Matt Mackall <[hidden email]> wrote:
> > On Fri, 2008-12-12 at 15:31 -0800, Peter Loron wrote:
> >> On Dec 10, 2008, at 4:36 PM, TK Soh wrote:
> >>
> >> > On Wed, Dec 10, 2008 at 3:54 PM, Peter Arrenbrecht
> >> > <[hidden email]> wrote:
> >> >> On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
> >> >> <[hidden email]> wrote:
> >> >>> Second issue, related: resolve without any arguments will
> >> >>> just overwrite a fixed conflict, discarding any changes
> >> >>> made.
> >> >>>
> >> >>> It should warn/ask the user interactively whether they
> >> >>> really want to do that. Alternative: no default behaviour
> >> >>> at all and a new switch that will restore the original
> >> >>> conflicts.
> >> >>
> >> >> +1. This has bitten me more than once, too. But maybe it's too late
> >> >> for removing the default (backward compat rules).
> >> >
> >> > If the rules have to be broken, it's better to do it while 1.1 is
> >> > still 'warm'.
> >>
> >> +2  This would be a very good change.
> >
> > Sorry, you only get one vote.
> >
> > We plan to add a new -a switch analogous to revert's.
>
> But no change to the default behaviour, meaning `hg resolve the/file`
> will clobber any manual resolving I've already done when I meant to
> say `hg resolve -m the/file`?

Yes. 'resolve' is a English verb. If you 'resolve a problem', you're not
'marking a problem as solved', you are 'taking steps to solve a
problem'.

Which is why the svn command is in the past tense: 'I've already fixed
it'. As far as I know, svn doesn't have a built-in concept of helping
you fix it by launching a tool with all the appropriate versions.

The current default behavior is precisely the one people have asked for:
"I did a merge wrong and something broke and I want to try it again".
Fewer people asked for "show me a list of files that still need
merging" (resolve -l). And I'm pretty sure no one ever said "hey, can we
have svn's resolved command?" I didn't even know it existed until
recently and if I had, I would have chosen a different name.

Further, if you're doing:

hg merge
emacs foo.c  # sort out conflict markers or otherwise manually merge
hg resolve -m foo.c

..you're making more work for yourself. You're supposed to be doing:

hg merge
hg resolve foo.c  # use a merge tool

The slow path exists and is allowed, of course, but I'm not going to
make the common fast path harder to make the slow path easier.

--
Mathematics is the supreme nostalgia of our time.

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Brendan Cully
In reply to this post by Peter Arrenbrecht
On Friday, 19 December 2008 at 21:43, Peter Arrenbrecht wrote:

> On Fri, Dec 19, 2008 at 9:29 PM, Dirkjan Ochtman <[hidden email]> wrote:
> > On 19/12/2008 10:07, Peter Arrenbrecht wrote:
> >>
> >> But no change to the default behaviour, meaning `hg resolve the/file`
> >> will clobber any manual resolving I've already done when I meant to
> >> say `hg resolve -m the/file`?
> >
> > The idea is that hg resolve without -a will be equivalent to -l.
>
> But will `hg resolve the/file` still clobber work? I rarely just say
> `hg resolve`, so the -a fix is not much of a help to me.
> -parren

Right now merge files have two states, 'marked' (resolved) and
'unmarked' (need resolving). How about we add a third state,
'modified', which means that the file has been changed by the user
since the last resolution attempt (eg if the user has manually fixed
up the file). Attempting to merge a file in this state would abort
with a warning (unless you used -f), and you could use resolve -u to
put the file into 'unmarked' state so that a subsequent resolve would
start over on that file, clobbering the working dir changes.
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Peter Arrenbrecht
In reply to this post by Matt Mackall
On Fri, Dec 19, 2008 at 10:01 PM, Matt Mackall <[hidden email]> wrote:

> On Fri, 2008-12-19 at 10:07 +0100, Peter Arrenbrecht wrote:
>> On Thu, Dec 18, 2008 at 6:26 PM, Matt Mackall <[hidden email]> wrote:
>> > On Fri, 2008-12-12 at 15:31 -0800, Peter Loron wrote:
>> >> On Dec 10, 2008, at 4:36 PM, TK Soh wrote:
>> >>
>> >> > On Wed, Dec 10, 2008 at 3:54 PM, Peter Arrenbrecht
>> >> > <[hidden email]> wrote:
>> >> >> On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
>> >> >> <[hidden email]> wrote:
>> >> >>> Second issue, related: resolve without any arguments will
>> >> >>> just overwrite a fixed conflict, discarding any changes
>> >> >>> made.
>> >> >>>
>> >> >>> It should warn/ask the user interactively whether they
>> >> >>> really want to do that. Alternative: no default behaviour
>> >> >>> at all and a new switch that will restore the original
>> >> >>> conflicts.
>> >> >>
>> >> >> +1. This has bitten me more than once, too. But maybe it's too late
>> >> >> for removing the default (backward compat rules).
>> >> >
>> >> > If the rules have to be broken, it's better to do it while 1.1 is
>> >> > still 'warm'.
>> >>
>> >> +2  This would be a very good change.
>> >
>> > Sorry, you only get one vote.
>> >
>> > We plan to add a new -a switch analogous to revert's.
>>
>> But no change to the default behaviour, meaning `hg resolve the/file`
>> will clobber any manual resolving I've already done when I meant to
>> say `hg resolve -m the/file`?
>
> Yes. 'resolve' is a English verb. If you 'resolve a problem', you're not
> 'marking a problem as solved', you are 'taking steps to solve a
> problem'.
>
> Which is why the svn command is in the past tense: 'I've already fixed
> it'. As far as I know, svn doesn't have a built-in concept of helping
> you fix it by launching a tool with all the appropriate versions.

Indeed. Only I think the part of this that Hg does for me is not the
"resolving", but the "merging" (or, even more precisely, "atttempt at
automated merging"). Witness this line emitted by `hg merge`:

  1 files updated, 1 files merged, 0 files removed, 2 files unresolved

When I get this, the unresolved files already contain the best attempt
Hg could make: clean cases are merged, conflicts are flagged. Maybe
I'm missing something here, but for me, there is no difference in tool
choice between `hg merge` and `hg resolve`. So I don't see how `hg
resolve` should use a different term than `hg merge`.

Given such conflicts, it's now my turn. I go and resolve the
conflicts. So "resolve" is what I do, not Hg. Which leads me to think
a command set such as

  hg resolved  --  marks a file as cleanly merged
  hg resolved -u -- marks as unresolved
  hg resolved -l -- lists conflict resolution states of files
  hg remerge  --  retries a clean merge on the given file(s), or --all

would be more consistent and lead to less unfortunate surprises.

And, though this is debatable, we could say that `hg merge`, when
called with an uncommitted merge, is equivalent to `hg resolved -l`,
albeit with a hint that this is an existing uncommitted merge.

>
> The current default behavior is precisely the one people have asked for:
> "I did a merge wrong and something broke and I want to try it again".
> Fewer people asked for "show me a list of files that still need
> merging" (resolve -l). And I'm pretty sure no one ever said "hey, can we
> have svn's resolved command?" I didn't even know it existed until
> recently and if I had, I would have chosen a different name.
>
> Further, if you're doing:
>
> hg merge
> emacs foo.c  # sort out conflict markers or otherwise manually merge
> hg resolve -m foo.c
>
> ..you're making more work for yourself. You're supposed to be doing:
>
> hg merge
> hg resolve foo.c  # use a merge tool

This is where you lose me. On my machine, merge and resolve don't use
different tools. Both try the internal merge, then launch meld if
there are conflicts.

> The slow path exists and is allowed, of course, but I'm not going to
> make the common fast path harder to make the slow path easier.

-parren
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Dirkjan Ochtman
In reply to this post by Brendan Cully
On 20/12/2008 23:32, Brendan Cully wrote:
> Right now merge files have two states, 'marked' (resolved) and
> 'unmarked' (need resolving). How about we add a third state,
> 'modified', which means that the file has been changed by the user
> since the last resolution attempt (eg if the user has manually fixed
> up the file). Attempting to merge a file in this state would abort
> with a warning (unless you used -f), and you could use resolve -u to
> put the file into 'unmarked' state so that a subsequent resolve would
> start over on that file, clobbering the working dir changes.

That sounds like exactly what we need.

Cheers,

Dirkjan
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Stefan Ring-2
In reply to this post by Peter Arrenbrecht
Peter Arrenbrecht <peter.arrenbrecht <at> gmail.com> writes:

> Indeed. Only I think the part of this that Hg does for me is not the
> "resolving", but the "merging" (or, even more precisely, "atttempt at
> automated merging"). Witness this line emitted by `hg merge`:
>
>   1 files updated, 1 files merged, 0 files removed, 2 files unresolved
>
> When I get this, the unresolved files already contain the best attempt
> Hg could make: clean cases are merged, conflicts are flagged. Maybe
> I'm missing something here, but for me, there is no difference in tool
> choice between `hg merge` and `hg resolve`. So I don't see how `hg
> resolve` should use a different term than `hg merge`.
>
> Given such conflicts, it's now my turn. I go and resolve the
> conflicts. So "resolve" is what I do, not Hg. Which leads me to think
> a command set such as
>
>   hg resolved  --  marks a file as cleanly merged
>   hg resolved -u -- marks as unresolved
>   hg resolved -l -- lists conflict resolution states of files
>   hg remerge  --  retries a clean merge on the given file(s), or --all
>
> would be more consistent and lead to less unfortunate surprises.
>
> And, though this is debatable, we could say that `hg merge`, when
> called with an uncommitted merge, is equivalent to `hg resolved -l`,
> albeit with a hint that this is an existing uncommitted merge.

I strongly agree with Peter.

Especially when coming from a pre-1.1 Mercurial, the new behavior makes no sense
at all. Before 1.1, I always performed the following steps:

1. hg merge
2. resolve conflicts (if any)
3. commit

Now when I try this in 1.1, commit tells me that I have to resolve first. So I
do as I'm told and type "hg resolve", and all my work from step 2 gets silently
thrown away.

I would not be as infuriated if the failed commit would not tell me to resolve,
knowing fully well that this very command would destroy the work I've done. At
least put a big warning right there not to type "hg resolve" without arguments.

Stefan

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Matt Mackall
On Sun, 2009-01-18 at 18:33 +0000, Stefan Ring wrote:

> Peter Arrenbrecht <peter.arrenbrecht <at> gmail.com> writes:
>
> > Indeed. Only I think the part of this that Hg does for me is not the
> > "resolving", but the "merging" (or, even more precisely, "atttempt at
> > automated merging"). Witness this line emitted by `hg merge`:
> >
> >   1 files updated, 1 files merged, 0 files removed, 2 files unresolved
> >
> > When I get this, the unresolved files already contain the best attempt
> > Hg could make: clean cases are merged, conflicts are flagged. Maybe
> > I'm missing something here, but for me, there is no difference in tool
> > choice between `hg merge` and `hg resolve`. So I don't see how `hg
> > resolve` should use a different term than `hg merge`.
> >
> > Given such conflicts, it's now my turn. I go and resolve the
> > conflicts. So "resolve" is what I do, not Hg. Which leads me to think
> > a command set such as
> >
> >   hg resolved  --  marks a file as cleanly merged
> >   hg resolved -u -- marks as unresolved
> >   hg resolved -l -- lists conflict resolution states of files
> >   hg remerge  --  retries a clean merge on the given file(s), or --all
> >
> > would be more consistent and lead to less unfortunate surprises.
> >
> > And, though this is debatable, we could say that `hg merge`, when
> > called with an uncommitted merge, is equivalent to `hg resolved -l`,
> > albeit with a hint that this is an existing uncommitted merge.
>
> I strongly agree with Peter.
>
> Especially when coming from a pre-1.1 Mercurial, the new behavior makes no sense
> at all. Before 1.1, I always performed the following steps:
>
> 1. hg merge
> 2. resolve conflicts (if any)
> 3. commit
>
> Now when I try this in 1.1, commit tells me that I have to resolve first. So I
> do as I'm told and type "hg resolve", and all my work from step 2 gets silently
> thrown away.
>
> I would not be as infuriated if the failed commit would not tell me to resolve,
> knowing fully well that this very command would destroy the work I've done. At
> least put a big warning right there not to type "hg resolve" without arguments.

hg resolve with no arguments does nothing in >= 1.1.1

--
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: hg resolve

Stefan Ring-2
Matt Mackall wrote:
>> I would not be as infuriated if the failed commit would not tell me to resolve,
>> knowing fully well that this very command would destroy the work I've done. At
>> least put a big warning right there not to type "hg resolve" without arguments.
>
> hg resolve with no arguments does nothing in >= 1.1.1

Good to know ;)
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial