[PATCH] commit: add --allow-empty flag

Gregory Szorc gregory.szorc at gmail.com
Sat May 9 11:50:58 CDT 2015


On Fri, May 8, 2015 at 12:30 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 05/08/2015 11:45 AM, Ryan McElroy wrote:
>
>> On 5/8/2015 10:41 AM, Pierre-Yves David wrote:
>>
>>>
>>>
>>> On 05/07/2015 03:10 PM, Durham Goode wrote:
>>>
>>>> # HG changeset patch
>>>> # User Durham Goode <durham at fb.com>
>>>> # Date 1431034538 25200
>>>> #      Thu May 07 14:35:38 2015 -0700
>>>> # Node ID 9f90e53f8e810db2d6b0e4cf66433166c4d42934
>>>> # Parent  c5d4f9cc8da7bb2068457e96e4f74ff694514ced
>>>> commit: add --allow-empty flag
>>>>
>>>
>>> I'm -1 on adding the new flag and +1 on the ability in core.
>>>
>>> Given that apparently multiple users exists for that and that
>>> conversion from other VCS requires it, it makes sense to make it
>>> somewhat available.
>>>
>>> However it is still far too much a corner case to be a first class
>>> citizen. Moreover, the most probable usage of that are automation who
>>> do not really care about the extra hurdle of going through something
>>> more complicated.
>>> Commit is an important user facing command and its option tend to
>>> trickle down to a lot of other commands. In my opinion. This feature
>>> is not generic/useful for normal user enough to justify a dedicated flag.
>>>
>>> I would go for a config option probably in the [ui] section.
>>>
>>> As Augie mentioned, we also have to make sure
>>> rebase/graft/histedit/etc preserve them.
>>>
>>>
>>>  I don't like the idea of having it as a config option, and [ui] doesn't
>> seem like that right place for it anyway. Reasons against a config
>> option: as a user, this is something that you want to enable on a
>> per-command basis. Having it as a ui option implies stickiness is
>> desired, but that is generally not the case here (in my experience using
>> this functionality in git -- which I used
>> not-as-rarely-as-you-would-think).
>>
>
> Okay, this is new informations. The only creators of such changesets in
> usecase have heard about so far are automated. But you seems to implies
> normal user may want to do so. What is your human usecase for it and why is
> it so frequent ?


At Mozilla, pushes to our "try" server contain a special "trychooser"
commit that specifies what jobs to run. This is an empty commit: all
metadata is conveyed via the commit message.

While we have some tools for managing this commit automatically, many users
rely on MQ for this role. As it stands, MQ is the best available mechanism
in the Mercurial distribution for doing this. I'd love to see one less
legitimate use of MQ.

For the record, if we were starting from scratch, we probably wouldn't use
empty trychooser commits. But it's been part of our workflow for years and
it isn't changing any time soon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150509/afa9117e/attachment.html>


More information about the Mercurial-devel mailing list