hg cp behaviour (was: [PATCH 0 of 5] keyword: safer copy/rename, safer search/substitution)

Christian Ebert blacktrash at gmx.net
Thu Sep 30 18:36:27 CDT 2010


* Christian Ebert on Thursday, September 30, 2010 at 02:19:50 +0200
> I extended my recently sent series with a 2nd security
> enhancement regarding unwanted keyword (un)expansion:
> 
> 1) handle copying/renaming to a destination not configured for
>   keyword expansion gracefully (4th patch)

Ok, hold it ;-) I can do this better with dirstate, but also I
discovered a strange behaviour of copy:

$ ls -l y
lrwxr-xr-x  1 chris  chris  1 Oct  1 00:38 y -> a
$ hg cp y z
$ ls -l z
lrwxr-xr-x  1 chris  chris  1 Oct  1 01:26 z -> a
$ hg forget z; rm z
$ cp y z
$ hg cp -A y z
$ ls -l z
-rw-r--r--  1 chris  chris  74 Oct  1 01:26 z

i.e. hg copy behaves like cp -R (on MacOS). But hg copy -A
accepts the file copied from a symlink as copy.

Is this expected/inentional?

Anyway, I found a way to solve/work around this for the keyword
extension.

c
-- 
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions


More information about the Mercurial-devel mailing list