[PATCH STABLE RFC] transplant: abort early if commit finds nothing to commit

[Martin Geisler]

Greg Ward <greg-hg at gerg.ca> writes:

> On Thu, Jul 1, 2010 at 1:33 PM, Greg Ward <greg-hg at gerg.ca> wrote:
>> # HG changeset patch
>> # User Greg Ward <greg-hg at gerg.ca>
>> # Date 1278001885 14400
>> # Branch stable
>> # Node ID e71642ce17bd129e5a75d558a7f029aab136ddd8
>> # Parent  b2468fb58b2bbbe5711119437449f253fda68318
>> transplant: abort early if commit finds nothing to commit
>> (partially addresses issue2135)
> [...]
>> --- a/hgext/transplant.py
>> +++ b/hgext/transplant.py
>> @@ -246,6 +246,17 @@
>>             m = match.exact(repo.root, '', files)
>>
>>         n = repo.commit(message, user, date, extra=extra, match=m)
>> +        if not n:
>> +            # Aborting here prevents an unclear crash later, in
>> +            # transplants.write().  This can happen if patch.patch()
>> +            # does nothing but claims success or if repo.status() fails
>> +            # to report changes done by patch.patch().  These both
>> +            # appear to be bugs in other parts of Mercurial, so perhaps
>> +            # Abort is the wrong exception to use.  But dying here, as
>> +            # soon as we can detect the problem, seems preferable to
>> +            # silently putting a bad tuple in the transplants object,
>> +            # causing it to crash in write().
>> +            raise util.Abort(_('nothing committed after transplant'))
>
> The more I think about this patch, the more I think it's right
> *except* it raise something other than Abort.  This is not the user's
> fault, and there is nothing the user can do about it.  It's a bug in
> Mercurial, and crashing here just makes sure the problem is detected
> and reported early and explicitly.

Do you still want us to apply this for Mercurial 1.7?

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/