Git has a useful (but somewhat ambiguously named) option 'core.filemode' which can be set to False to ignore changes in the file mode (specifically the executable bit in the file mode). This is useful when working with a posix application on what Git lovingly refers to as "broken filesystems like FAT", by which it means those that aren't designed to have an execution bit. Personally, I would find this really useful as I use Cygwin on Windows a lot and find that using Windows editors will make Cygwin think that the execution bit has been set.
For someone else's investigation into this (and the rather ineffective and crude work-around they had to use), see: http://stackoverflow.com/questions/5073115/mercurial-ignore-file-permission-mode-chmod-changes
My workaround was to use sshfs with umask=0177 to mount the Windows directory on a Linux machine and commit there. But yes, having a config option for this would be nice. Until then you could use a mini extension which patches mercurial.util.checkexec() or something like that.
As I've already noted, I'm philosophically opposed to this approach. Please explain the problem you're having with exec bits instead so we can fix it.
For starters, what does 'hg debugfs' report?
As I said in my email on the patch thread: Unfortunately, the problem is with Windows applications not knowing anything about Cygwin permissions and hence setting the executable bit (as far as Cygwin is concerned). In Git I can easily work round this with "core.filemode = false". The only time I really have an issue with it is with version control systems, so if I use Git there is no problem. If you don't want this option to be offered in Mercurial, is there any way I could do it with an extension? It looked a bit too 'core' to me to be possible in an extension, but then I've never written a Mercurial extension before... I'm not in front of a Windows PC at the moment, but I can try "hg debugfs" tomorrow if you think it will help.
* Matt Mackall <bugs@mercurial.selenic.com> [20120306 17:53]: > For starters, what does 'hg debugfs' report? In my case: exec: yes symlink: yes case-sensitive: yes But I have a special layout which causes this, since I have a directory on Linux (XFS fs) which contains .hg, .hgignore and mountpoints of NTFS filesystems mounted via sshfs from a Windows machine. So having the config option "would be nice" (as wrote in my earlier comment), but since this is a very special situation and I have a workaround, it is not that important for me. Regards, Thomas
'hg debugfs' reports: exec: yes symlink: yes case-sensitive: no To reproduce the issue using Mercurial in Cygwin: $ hg version Mercurial Distributed SCM (version 2.1+17-e1d8218d733b) (see http://mercurial.selenic.com for more information) Copyright (C) 2005-2012 Matt Mackall and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ hg init testdir $ cd testdir $ echo abc > a $ hg add a $ hg ci -mx $ ls -oF total 1 -rw-r--r-- 1 al 4 Mar 7 13:26 a $ hg st $ hg diff --git # Now open the file in a Windows editor that internally # uses a temporary file and hence creates a new file on # write (quite common on editors with large file support). # Save the file without changing anything. $ ls -oF total 1 -rwxr-xr-x 1 al 4 Mar 7 13:28 a* $ hg st M a $ hg diff --git diff --git a/a b/a old mode 100644 new mode 100755 $ notepad b.txt # In response to "Cannot find the b.txt file. # Do you want to create a new file?", answer Yes. # Add some text. # File...Save, File...Quit $ ls -oF total 2 -rwxr-xr-x 1 al 4 Mar 7 13:28 a* -rwxr-xr-x 1 al 4 Mar 7 13:30 b.txt* $ hg add b.txt $ hg st M a A b.txt $ hg diff --git diff --git a/a b/a old mode 100644 new mode 100755 diff --git a/b.txt b/b.txt new file mode 100755 --- /dev/null +++ b/b.txt @@ -0,0 +1,1 @@ +test \ No newline at end of file
Ok, now that I've read through the horrible machinations involved in translating POSIX permissions to native ACLs in Cygwin, my inclination is to simply disable support for exec bits when in Cygwin by default. First, given than Windows programs won't respect anything like a umask and things will thus randomly show up with exec bits when edited or copied by non-Cygwin tools, this exec bit doesn't behave like a normal exec bit at all. Second, people who use hg in both Cygwin and native on the same machine will get very strange results. Also, my inclination is to disable support for symlinks here as well, for the same reasons. Then, I might consider an optional feature to re-enable them, in case there are any Cygwin purists *cough* out there.
sounds like a single configuration option: yes/no/automatic (with auto being the default)
yes/no/auto (not automatic) to match the EOL option
> Ok, now that I've read through the horrible machinations involved in > translating POSIX permissions to native ACLs in Cygwin, my inclination > is to simply disable support for exec bits when in Cygwin by default. That certainly sounds good to me. Is that an easy fix? > Also, my inclination is to disable support for symlinks here as well, > for the same reasons. I have no strong preference on this: I do use symlinks in Cygwin occasionally, but only for things like having a ~/Desktop link to c:\Documents\ and\ Settings\A\ Budden\Desktop, not inside any VCS- controlled projects. Whether or not Mercurial supports symlinks in Cygwin is of no consequence to me. > Then, I might consider an optional feature to re-enable them, in case > there are any Cygwin purists *cough* out there. ThomasAH's yes/no/auto suggestion sounds sensible to me, although I'd probably leave it on auto...
Search for 'cygwin' in mercurial/posix.py and add a new definition for checkexec. We'll leave off the config setting until someone says they need it.
Fixed by http://selenic.com/repo/hg/rev/95e45abe7e8e A. S. Budden <abudden@gmail.com> posix: ignore execution bit in cygwin (issue3301) (please test the fix)
> (please test the fix) I've tested http://selenic.com/repo/hg/ at revision 60cc3a0d2249. Looks good to me.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:28 EDT --- This bug was previously known as _bug_ 3301 at http://mercurial.selenic.com/bts/issue3301