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

Pierre-Yves David pierre-yves.david at logilab.fr
Tue Oct 2 12:24:54 CDT 2012

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 

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

> >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


-------------- 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>

More information about the Mercurial-devel mailing list