[PATCH] copy: distinguish "file exists" cases and add a hint (BC)
pierre-yves.david at ens-lyon.org
Wed Sep 28 08:28:02 EDT 2016
On 09/27/2016 10:37 PM, Augie Fackler wrote:
>> On Sep 27, 2016, at 11:23, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>> On 09/26/2016 10:36 PM, Augie Fackler wrote:
>>> # HG changeset patch
>>> # User Augie Fackler <augie at google.com>
>>> # Date 1474319739 14400
>>> # Mon Sep 19 17:15:39 2016 -0400
>>> # Node ID a1b65d0019f9ce96961c5c9533a8658a92e5b9d4
>>> # Parent 129e38a76f2ca43291ed3a12d92b5d4b7e3b7f2b
>>> copy: distinguish "file exists" cases and add a hint (BC)
> I'll get a v4 rolled tonight yet, assuming it doesn't turn out twisty and confusing to thread the action down into cmdutil.
>>> Users that want to add a copy record to an existing commit with 'hg
>>> commit --amend' should be guided towards this workflow, rather than
>>> reaching for some sort of uncommit-recommit flow. As part of this,
>>> distinguish in the top-line error message whether the file merely
>>> already exists (untracked) on disk or the file already exists in
>> Small side not. being able to record the copy after the fact is great and that is great that this changesets work toward making it more discoverable. Another important point would be to allow the same thing for move.
>>> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
>>> --- a/mercurial/cmdutil.py
>>> +++ b/mercurial/cmdutil.py
>>> @@ -640,8 +640,15 @@ def copy(ui, repo, pats, opts, rename=Fa
>>> if not after and exists or after and state in 'mn':
>>> if not opts['force']:
>>> - ui.warn(_('%s: not overwriting - file exists\n') %
>>> - reltarget)
>>> + if state in 'mn':
>>> + msg = _('%s: not overwriting - file already committed\n')
>>> + hint = _('(hg copy --after --force to replace the '
>>> + 'file by recording a copy)\n')
>> This "replace" here is confusing. --after seems to point out that no actual replacement occurs, just a 'recording'. Why does this message mention 'replace' in addition to 'record'.
> Folks on irc were very insistent that the word replace matters, notably timeless. My algorithm is that timeless is right about these things pretty much by default, so I went with a tweak of his wording. I'm not going to change this in the next version unless I hear a lot about it from native speakers.
> (I agree the word replace here is a little odd, but it's not strictly wrong data-model wise, and the hint text is very much something we can tweak if it's a problem in the real world.)
I'm curious about the timeless reasoning around using "replace" for a
pure book keeping operation that does not replace the file content. (But
not challenging that timeless is most probably right). Timeless can you
elaborate a bit ?
More information about the Mercurial-devel