[MERGE] auto-resolve for commit

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> I'm not sure about auto resolving on commit. However, I think a 'bzr
>>> resolve --check' would be a very good place for this.
> 
> Could you explain why that's an improvement?  From my POV, we shouldn't
> ask the user to tell us what we already know.  What's the advantage of
> the resolve step?

My gut feeling is that 'commit' time isn't the right time for mutating
the tree.  Especially because of:

$ bzr status
# This shows conflicts
$ bzr commit -m 'forgot about conflicts'
# This succeeds??

Even worse is that doing a plain 'bzr commit' is going to show in the
little summary that there are conflicts, and you are just supposed to
ignore that because you know you resolved those problems.

Further, it doesn't resolve all conflicts, so people might be used to
having bzr infer the conflict status from the tree, and then when it
can't they get confused.

It seems best to have the user specifically ask bzr to check for cleaned
up conflicts. Now it may be that we should do this on any tree-analyzing
command. So status/diff/info/etc all check to make sure conflicted files
are really conflicted.

To me, 'commit' is record this state in history, which is a more
sensitive time to be changing things. I'm not strict on it. If the above
issues were addressed, maybe I would find the new mode absolutely
wonderful. Certainly I know we try to stay out of the user's way when
possible.

So I'd be happiest in the short term with 'bzr resolve --check'. But
since Martin seems happy with commit resolving things, I may be the odd
man out.

> 
>>> Actually, I would
>>> even consider 'bzr resolve --all' should actually perform this check.
>>> While 'bzr resolve foo/bar' would sledgehammer that the conflict is
>>> resolved.
> 
> I don't think people would like this.
> 
>>> Further, I think you could use the regex:
>>>
>>> '^(<{7}|={7}|>{7})'
> 
> I used re.match, which will not match unless the regex matches at the
> beginning of the line.  So the '^' is redundant.
> 
> Aaron

True enough. I don't know if we would want to put '$' at the end, since
re.match() *doesn't* check that the whole pattern matches, just that it
matches at the start of the string:
>>> re.match('foo', 'foobar').group()
'foo'

I can also argue that I was a little confused because where the regex is
defined is separate from where it is used. So it isn't clear when
evaluating the regex whether search or match is going to be used. But I
certainly wouldn't block on you changing it.

John
=:->

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