Siddharth Agarwal <sid0@fb.com> [Sun, 08 Nov 2015 23:42:44 -0800] rev 26893
filemerge: move :merge-local/other symlink check to precheck
In upcoming patches we're going to add more checks to the function currently
named _symlinkcheck. This consolidates all those checks.
Siddharth Agarwal <sid0@fb.com> [Sun, 08 Nov 2015 23:47:20 -0800] rev 26892
test-merge-types.t: add tests for :merge-local/:merge-other with symlinks
This had no test coverage.
Matt Mackall <mpm@selenic.com> [Mon, 09 Nov 2015 16:24:13 -0600] rev 26891
Added signature for changeset 1aa5083cbebb
Matt Mackall <mpm@selenic.com> [Mon, 09 Nov 2015 16:24:08 -0600] rev 26890
Added tag 3.6.1 for changeset 1aa5083cbebb
Matt Mackall <mpm@selenic.com> [Mon, 09 Nov 2015 15:53:11 -0600] rev 26889
posix: fix test-permissions regression
Anton Shestakov <av6@dwimlabs.net> [Sun, 08 Nov 2015 01:10:52 +0800] rev 26888
dockerlib: allow non-unique uid and gid of $DBUILDUSER (issue4657)
There are make targets for building mercurial packages for various
distributions using docker. One of the preparation steps before building is to
create inside the docker image a user with the same uid/gid as the current user
on the host system, so that the resulting files have appropriate
ownership/permissions.
It's possible to run `make docker-<distro>` as a user with uid or gid that is
already present in a vanilla docker container of that distibution. For example,
issue4657 is about failing to build fedora packages as a user with uid=999 and
gid=999 because these ids are already used in fedora, and groupadd fails.
useradd would fail too, if the flow ever got to it (and there was a user with
such uid already).
A straightforward (maybe too much) way to fix this is to allow non-unique uid
and gid for the new user and group that get created inside the image. I'm not
sure of the implications of this, but marmoute encouraged me to try and send
this patch for stable.
Mateusz Kwapich <mitrandir@fb.com> [Mon, 09 Nov 2015 10:43:23 -0800] rev 26887
dirstate: fix filefoldmap incosistency on file delete
The _filefoldmap is not updated in when files are deleted from dirstate. In the
case where the file with the same but differently cased name is added afterwards
it renders _filefoldmap incorrect. Those steps must occur to for a problem to
reproduce:
- call status (with listunknown=True),
- update working rectory to a commit which does a casefolding change (A -> a)
- call status again (it will show the file "a" as deleted)
Unfortunately I'm unable to write a test for it because I don't know any
core-mercurial command able to reproduce those steps.
The bug was originally spotted when hgwatchman was enabled. It caused the
changeset contents change during hg rebase (one file unrelarted to changeset
was deleted in it after rebase).
The hgwatchman is able to hit it because when hgignore changes the hgwatchmans
overridestatus is calling original status with listunknown=True.