windows: recompute flags when committing a merge (issue1802)
Before this patch, Windows always did the wrong thing with exec bits
when committing a merge: consult the flags in first parent.
Now we manually recompute the result of merging flags at commit time,
which almost always does the right thing (except when there are
conflicts between symlink and exec flags).
To do this, we:
- pull flag synthesis out into its own function
- delay building this function unless it's needed
- add a merge case that compares flags in local and other against the ancestor
This has been tested in multiple ways on Linux:
- running the whole test suite with both old and new code in place,
checking for differences in each flags() result
- running the whole test suite while comparing real on-disk flags
against synthetic ones for merges
- test-issue1802 (from Martin Geisler) which disables exec bit
checking on Unix
$ cat >> $HGRCPATH <<EOF
> [extensions]
> convert=
> EOF
Prepare orig repo
$ hg init orig
$ cd orig
$ echo foo > foo
$ HGUSER='user name' hg ci -qAm 'foo'
$ cd ..
Explicit --authors
$ cat > authormap.txt <<EOF
> user name = Long User Name
>
> # comment
> this line is ignored
> EOF
$ hg convert --authors authormap.txt orig new
initializing destination new repository
Ignoring bad line in author map file authormap.txt: this line is ignored
scanning source...
sorting...
converting...
0 foo
Writing author map file $TESTTMP/new/.hg/authormap
$ cat new/.hg/authormap
user name=Long User Name
$ hg -Rnew log
changeset: 0:d89716e88087
tag: tip
user: Long User Name
date: Thu Jan 01 00:00:00 1970 +0000
summary: foo
$ rm -rf new
Implicit .hg/authormap
$ hg init new
$ mv authormap.txt new/.hg/authormap
$ hg convert orig new
Ignoring bad line in author map file $TESTTMP/new/.hg/authormap: this line is ignored
scanning source...
sorting...
converting...
0 foo
$ hg -Rnew log
changeset: 0:d89716e88087
tag: tip
user: Long User Name
date: Thu Jan 01 00:00:00 1970 +0000
summary: foo