Re: git on Cygwin: Not a valid object name HEAD

From: Steffen Prohaska <prohaska@zib.de>
Date: Aug 8, 2007, 05:46 UTC
Message-ID: <11631546-D4E4-491A-8A12-98A42043C535@zib.de>
In-Reply-To: <20070808042513.GP21692@lavos.net>

On Aug 8, 2007, at 6:25 AM, Brian Downing wrote:

Show 17 quoted lines

> On Wed, Aug 08, 2007 at 12:46:49AM +0200, Steffen Prohaska wrote:
>> I started to run the tests on cygwin in textmode. I chose the
>> following setup.
>
> In addition to all the other stuff discussed, I believe you also need
> to worry about the binaryness of stdin and stdout.
>
> Looking at:
>
> http://www.cygwin.com/cygwin-ug-net/using-textbinary.html
>
> I think this can be achieved by putting something like:
>
> 	setmode(0, O_BINARY);
> 	setmode(1, O_BINARY);
>
> at the start of git's main().

I agree. This is my understanding as well.

Show 5 quoted lines

> When I was trying to get this to work, I did this as well as fixing up
> open() and fopen() calls as has already been discussed.  What got me
> to quit, however, was that I never found a decent way to make the Git
> shell scripts binary safe, and enough of the system was in shell as to
> make it pretty much useless for everyday use.

Did you find a way, maybe not as decent as you wished?

Show 26 quoted lines

> Looking at the examples on the above page:
>
>     To illustrate the various rules, we provide scripts to delete  
> CRs from
>     files by using the tr program, which can only write to standard  
> output.
>     The script
>
>     #!/bin/sh
>     # Remove \r from the file given as argument
>     tr -d '\r' < "$1" > "$1".nocr
>
>     will not work on a text mounted systems because the \r will be
>     reintroduced on writing. However scripts such as
>
>     #!/bin/sh
>     # Remove \r from the file given as argument
>     tr -d '\r' | gzip | gunzip > "$1".nocr
>
>     work fine. In the first case (assuming the pipes are binary) we  
> rely
>     on gunzip to set its output to binary mode, possibly overriding  
> the
>     mode used by the shell.
>
> was all it took to convince me this was probably a fool's errand.

Yeah, it looks quite crazy. I started to search for an option that would force the shell to provide redirection in binary mode, overriding the standard rules. I found the igncr option [1], which is not what I need. But apparently there have been some efforts to deal with line endings in bash beyond the cygwin standard rules. Maybe there's a useful option that I haven't found yet.

[1] http://cygwin.com/ml/cygwin-announce/2007-01/msg00015.html

> I wound up fixing our software so it would build on a binary mount,
> which I decided was a much more sane solution.

Well, our software already builds and I was not even aware that there is a problem with git on cygwin until I asked more people to test it. I naively chose the default option because I didn't have a reason to do otherwise. But apparently there is an option, and people use this option.

My fear is that the first impression of git is too bad on Windows if it can't handle textmode. I can't recommend it. People will make me responsible for recommending them a tool that only cause troubles or forces them to reconfigure their cygwin, which worked for them for years. I even remember that we had a policy to explicitly set cygwin to textmode to avoid problems with cvs commits in combination with Visual Studio 6.

	Steffen