[PATCH 1 of 2] simplemerge: includes revision into merge marker of simplemerge

[Pierre-Yves David]

On Thu, Sep 27, 2012 at 01:27:21PM +0200, Mads Kiilerich wrote:
> On 09/27/2012 12:06 PM, pierre-yves.david at logilab.fr wrote:
> ># HG changeset patch
> ># User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
> ># Date 1348738364 -7200
> ># Node ID ac1131f2927400cb0e031d6929cfa3ce07cf1a27
> ># Parent  d34ba4991188fdfa4f8322b9a32c4c08aaf6ff27
> >simplemerge: includes revision into merge marker of simplemerge
> >
> >Before this changes internal:merge conflict look like::
> >
> >   <<<<<<< local
> >   something else
> >   =======
> >   something
> >   >>>>>>> other
> >
> >With this changes they look like::
> >
> >   <<<<<<< local: 32e80765d7fe+
> >   something else
> >   =======
> >   something
> >   >>>>>>> other: 75234512624c
> 
> That is a behavioural change that might bite someone. That could be
> enough reason to reject this change.

I do not think that break anything else that people manually parse resulf
internal:merge. Are you thinking about any other case?

I do not think we support crazy guys who do rigid parsing of marker created by 
internal:merge.

If we find other valid case or if Matt state we support crazy guy, we'll have
to find something else.

> >The extra nodeid added refer to the last revision that touched the files in this
> >"branch" of the merge.
> 
> Really? AFAICS it will show the revisions that are merged, no matter
> if the file is touched in that revision or not.

May mistake, its false for `local` and `other` (they show revision being merge)
but true for the `base` (displayed in later changeset)

> Is that what you want or is it more like a kind of 'annotate' you
> are looking for?

I've not strong opinions on that. using merge revision may be clearer for new
user.

> >Such information should help to remove ambiguous about
> >each side of the merge. For example in rebase: `local` is destination and
> >`other` is rebased changesets. The only information added is the nodeid. This is
> >a simple a short information that allows to retrieves all the other (revid,
> >description, date, authors, etc).
> 
> Depending on what you want to show:
> 
> * Just showing the hash is not very useful for daily use. It would
> be more useful if it also showed the tags and bookmarks of the
> revisions. Also consider that 'annotate' by default uses revision
> numbers and not ids - this feature should perhaps do the same.

Nodeid is more stable than revision. I think personally find them more useful.
Your point about tag are bookmark is interesting. The format used may be:

    <<<<<<< local: 42:32e80765d7fe+ mybookmark mytag (mybranch?)


We do not have the same space constraint than annotate.

> * This feature can perhaps be handy for "debugging" hard merges. It
> could perhaps make sense to hide it behind a --debug or -v.

It's a very useful feature that helps to demystify merge for new user. You do
not really know that a merge will be hard before it actually fails. Moreover if
not advertised the feature will not be used at all.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121002/88f9b721/attachment.pgp>