On 07/21/2013 05:56 PM, Junio C Hamano wrote:
Ramsay Jones <ram...@ramsay1.demon.co.uk> writes:
Mark Levedahl wrote:
The supported Cygwin distribution on supported Windows versions provides
complete support for POSIX filemodes, so enable this by default.
Historical notes: Cygwin version 1.7 supports Windows-XP and newer, thus
dropped support for all OS variants that lack NTFS and/or ...
... Thus, POSIX filemode support
could not be expected by default on a Cygwin 1.5 installation, but is
expected by default on a 1.7 installation.
Again, I have to ask; should you not "revert" commit c869753e ("Force
to false on Cygwin.", 30-12-2006)? After this commit, there is no longer any
of the NO_TRUSTABLE_FILEMODE build variable, and no real prospect of anyone else
wanting to use it.
Thanks for raising this point.
Reading c869753e once again:
The issue is that Cygwin and NTFS correctly supports the
executable mode bit, and Git properly detected that, but most
native Windows applications tend to create files such that
Cygwin sees the executable bit set when it probably shouldn't
In other words, the reason why "NO_TRUSTABLE_FILEMODE" was added was
not because the Cygwin did not give us reliable filemodes. It was
because tools outside the control of Git and/or Cygwin that users
use tend to misbehave, even when the working tree is on a filesystem
on which Cygwin can give us trustable filemodes.
So "1.7 always supports core.filemodes correctly because it no
longer works on filesystems without trustable filemodes" is not a
valid reason to justify Mark's change.
There are only three possible ways going forward, I think:
(A) Drop Mark's patch, and do nothing else, because breakages of
other people's programs are not fixed by Cygwin 1.7's improved
filesystem support, and users still use those mode breaking
programs written by others;
(B) Drop Mark's patch, and revert c869753e, because it is not the
business of our project to sweep breakages of other people's
tools under the rug by crippling our software; or
(C) Drop NO_TRUSTABLE_FILEMODE for _all_ versions of Cygwin,
declaring that the spirit of c869753e to work around bugs in
other people's software by crippling Git is justified, but that
it is no longer necessary on Cygwin because people do not use
such misbehaving third-party tools anymore.
These three each rely on its own precondition; I suspect it is
likely that (A)'s is the most accurate description of the real world.
Perhaps the simplest approach is to just defer to the judgement of the
Cygwin project maintainers here.
a) The Cygwin project has its stated objective of being as matching Linux.
b) The Cygwin project has always shipped git binaries built without
Also - users who do not want Cygwin's assumptions / environment are now
free to use the msysgit version and frankly they should be so encouraged
- it is faster than Cygwin's git. This option was not available in 2006.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html