[PATCH 6 of 6 bid merge v2] [RFC] merge: take bids for merge actions for different ancestors and pick the best
Martin Geisler
martin at geisler.net
Mon Apr 21 08:28:34 CDT 2014
Mads Kiilerich <mads at kiilerich.com> writes:
> On 04/07/2014 02:20 AM, Mads Kiilerich wrote:
>> Most of the necessary preliminary refactorings from
>> http://markmail.org/message/r2lifdz5m5e5ynw7 have now been merged. I
>> have updated the remaining patches and will add some comments to
>> supplement the discussion of the patch actually implementing "bid
>> merge".
>
> This has been merged for 3.0.
>
> Bid merge is enabled by setting the configuration value
> "merge.preferancestor=*". With this setting, Mercurial will perform a
> bid merge in the cases where a merge otherwise would emit a "note:
> using X as ancestor of X and X" message.
>
> See http://mercurial.selenic.com/wiki/BidMerge for an updated online
> description of what it is.
Very nice! This makes my answer here obsolete in Mercurial 3.0:
http://stackoverflow.com/a/9430810/110204
There I create a criss-cross merge situation and show that picking
different ancestors can give different merge results -- with no
conflicts involved.
By the way, I think the message format is a little verbose and unusual
here:
$ hg merge
note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
alternatively, use --config merge.preferancestor=fdf4b78f5292
merging x
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
The hanging indentation looks unusual to my eyes. The hint is repeated
if there are multiple alternative ancestors and I think that looks even
more funny:
$ hg merge
note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
alternatively, use --config merge.preferancestor=fdf4b78f5292
alternatively, use --config merge.preferancestor=30c60e28aa9b
alternatively, use --config merge.preferancestor=a63958bcf63a
merging x
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
For a single alternative, I would suggest using the normal hint style:
$ hg merge
note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
(alternatively, use --config merge.preferancestor=fdf4b78f5292)
merging x
When there are multiple alternatives, I will argue that listing them
isn't super helpful: I think the kind of user who want this information
and who will know what to do with it will want to inspect the ancestors
before proceeding.
So my suggestion would be to instead include the log command needed to
see the ancestors. Something like:
$ hg merge
note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
(use 'hg log -r "heads(::333411d2f751 and ::7d1f71140c74)"' to see them all)
merging x
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
That's still a bit long and unhelpful -- people would still need to know
why they might want to pick another merge base. Maybe an even better
idea would be to refer people to a help topic. We could add a verbose
section to 'hg help merge' that describes this, for example.
I think the feature is undocumented right now -- I can add a paragraph
to 'hg help merge' and config.txt if people like that idea?
--
Martin Geisler
http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140421/50f0a60e/attachment.pgp>
More information about the Mercurial-devel
mailing list