[PATCH] revert: allow configuring the .orig file location

[Sean Farley]

Durham Goode <durham at fb.com> writes:

> On 8/12/15 10:11 AM, Augie Fackler wrote:
>> On Wed, Aug 12, 2015 at 1:00 PM, Durham Goode <durham at fb.com> wrote:
>>>> As a fraction of users, how bad is this? If it's 1% of your userbase
>>>> or some other low level, I'm inclined to tell them to suck it up, as
>>>> every feature introduces some extra maintenance complexity. Have you
>>>> pointed them to 'hg revert --no-backup'?
>>> It's not a large percentage, but then again, the majority of users don't
>>> give any feedback at all.  When they ask "why can't we just put the orig
>>> files somewhere else", me answering "suck it up" or "because it adds
>>> complexity" is kind of an embarrassing response for me for a relatively
>>> simple issue.
>> You're asking for a feature that to my knowledge NO version control
>> system has ever offered. It's also tiptoeing up to the line that will
>> probably make mpm nervous about scripts breaking (though I'm
>> personally less worried about that...). I get that it's relatively
>> simple, but a lot of "relatively simple" things in a complex codepath
>> (revert counts as one of those just from the reviews I've done for
>> marmoute!) add up to a nightmare for long-term maintainers.
> I don't actually know how other version control systems handle this, so 
> I can't really comment on that.
>
> If it would be less maintenance, I'd be fine making this config a 
> boolean that just tells mercurial to dump the orig files in 
> .hg/origfile-backups or something.  To take away the security and some 
> complexity costs.
>>
>>> Also, part of what I'm trying to do is set up Mercurial so that the defaults
>>> (for our users at least) result in the fewest questions for us.  This is
>>> just one of a number of nagging issues that cause questions, and the
>>> questions really add up when you onboard hundreds of new people each month.
>>> This particular case is one where the solution has zero downsides for the
>>> user, and trivial downsides for us hg developers.
>> A FAQ entry would probably also have zero downsides for your users and
>> have even fewer problems for maintainers.
> Unfortunately the percentage of people who read FAQs before asking 
> questions is rather low :/
>>
>>> In addition, --no-backup isn't really great since they do want backups, just
>>> not in their working copy. In fact, I think the refactor this patch does (of
>>> moving the .orig path creation logic somewhere central) is something we want
>>> anyway. This way we can reuse that logic elsewhere (like in hg update -C, so
>>> it wouldn't lose data either).
>> Fascinating. Are these users that have never used source control? Or
>> is there some mysterious feature in another VCS that you could/should
>> be pointing to as historical evidence for this kind of feature being
>> worthwhile?
> I see this feature as being the same as the setting in a build system 
> that lets you determine where the build outputs go.  It's just a way of 
> saying 'dump your crap over here and out of my way'.
>
> If the feature isn't worthwhile for upstream (I'll wait for Matt to 
> chime in), we can just submit a patch that does the refactor, then do an 
> internal extension to make it configurable.

For what it's worth, I've wanted this before but 1) forgot to ask and 2)
didn't have time to implement.