On 8/7/07, Sebastian Schuberth <sschuberth@gmail.com> wrote:
quoted text
> >>>  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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html