On 8/7/07, Sebastian Schuberth <sschuberth@xxxxxxxxx> wrote: > >>> 100% (2295/2295) done > >>> Resolving 1793 deltas... > >>> 100% (1793/1793) done > >>> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f > >>> fatal: Not a valid object name HEAD > > > I wonder if this happens because git never passes "b" to any fopen() > calls (as there is no such thing like opening a file in binary mode > under Linux, because files are always opened "binary"). If fopen() > safely ignores the "b" option under Linux, I think it should always be > specified so Cygwin's git will work with text mode mounts when compiled > from the original git sources. > > -- If you follow the Cygwin mailing lists, you'll find that the developers *really* want to kill off the whole text mount thing: ultimately, this has proved unsupportable as it requires deep modifications of every tool "ported" over to Cygwin and invariably leads to strange bugs as you have just discovered. Originally, Cygwin had the goal of porting Unix tools to Windows, requiring that every tool work on text mounts, but they restated their goal as providing a POSIX environment under Windows that matches what Linux does. So, I doubt you'll get support from the Cygwin developer's or the Cygwin git maintainer for a text mount aware version of git. Clearly, the mingw port has to deal with these issues, and it might be possible to leverage that work for Cygwin, but the flip side is that under POSIX, git explicitly recognizes the difference between \0d\0a and \0a while on a text mount, programs do not, and this would make such a ported git violate the currently stated Cygwin goals. Mark - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
