[PATCH] exchange: identify the troubled commit

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Dec 8 03:53:56 CST 2015



On 12/07/2015 08:40 PM, timeless wrote:
> # HG changeset patch
> # User timeless <timeless at mozdev.org>
> # Date 1449549446 0
> #      Tue Dec 08 04:37:26 2015 +0000
> # Node ID 7835c3c8bf67c5213c21276645442e21e4180b7d
> # Parent  42aa0e570eaa364a622bc4443b0bcb79b1100a58
> exchange: identify the troubled commit
>
> Exchange iterates over heads to quickly identify if everything is
> OK. But, users don't want to know the revision of the bad head,
> they need to know the revision of the bad commit.
>
> So, instead of identifying the faulty head, once we know there's
> a faulty head, iterate over all of outgoing and identify the
> specific commit that is troubled.
>
> This could be improved by only looking at revisions relating to
> the faulty head. But, since we're already failing, there's no real
> need for an optimized algorithm.
>
> diff --git a/mercurial/exchange.py b/mercurial/exchange.py
> --- a/mercurial/exchange.py
> +++ b/mercurial/exchange.py
> @@ -569,7 +569,10 @@
>                   if ctx.obsolete():
>                       raise error.Abort(mso % ctx)
>                   elif ctx.troubled():
> -                    raise error.Abort(mst[ctx.troubles()[0]] % ctx)
> +                    for tnode in outgoing.missing:
> +                        tctx = unfi[tnode]
> +                        if tctx.troubled():
> +                            raise error.Abort(mst[tctx.troubles()[0]] % tctx)

This change does not make too much sense to me in regard with the 
changesets description.

The way I read the changesets description, it looks like that:

   The warn about head X being bad while actually Y is the bad one.


However, reading the code,

If ctx.troubled() is True, There -is- trouble on ctx and reporting 
troubles on ctx isn't false.

I'm not sure what you are trying to achieve here.



In the other hand, this patch make me see an interresting step to 
improve this message. Looking at all outgoing changesets on error seems 
reasonable (ever If I would use set logic instead of ctx for speed 
purpose). We could give a more details report of "other issue"

   abort: push includes divergent changeset: 392fd25390da
   (and also other 42 unstables and 3 divergents changesets)

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list