git on Cygwin: Not a valid object name HEAD

git on Cygwin: Not a valid object name HEAD

[Sebastian Schuberth]

Hi,

I'm running git 1.5.2.2 under Cygwin on Windows XP. This is what I'm 
(reproducibly) getting if I try to clone QGit's repository:

sschuber@xp-sschuber2 ~
$ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git
Initialized empty Git repository in /home/sschuber/qgit4/.git/
remote: Generating pack...
remote: Done counting 2295 objects.
remote: Deltifying 2295 objects...
remote:  100% (2295/2295) done
Indexing 2295 objects...
remote: Total 2295 (delta 1793), reused 1218 (delta 955)
  100% (2295/2295) done
Resolving 1793 deltas...
  100% (1793/1793) done
: not a valid SHA1b870df7cde1e05ee76d1d15ea428f
fatal: Not a valid object name HEAD

sschuber@xp-sschuber2 ~
$ git --version
git version 1.5.2.2

I'm not sure whether the cause for this is the same as mentioned at

http://article.gmane.org/gmane.comp.version-control.git/54825

However, the most recent msysGit worked fine for me. Any clues whether 
this is a repository problem, a Cygwin problem, or a git problem?

Thanks.

-- 
Sebastian Schuberth

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

[Johannes Schindelin]

Hi,

On Tue, 7 Aug 2007, Sebastian Schuberth wrote:

>  100% (2295/2295) done
> Resolving 1793 deltas...
>  100% (1793/1793) done
> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f
> fatal: Not a valid object name HEAD

I suspect that there is no master branch on the remote side, but the 
remote's HEAD points there.  Try "git ls-remote <url>" to find out.

Ciao,
Dscho

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

[Sebastian Schuberth]

>>  100% (2295/2295) done
>> Resolving 1793 deltas...
>>  100% (1793/1793) done
>> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f
>> fatal: Not a valid object name HEAD
> 
> I suspect that there is no master branch on the remote side, but the 
> remote's HEAD points there.  Try "git ls-remote <url>" to find out.

I'm not too familiar with git yet, but to me this looks alright:

sschuber@xp-sschuber2 ~
$ git ls-remote git://git.kernel.org/pub/scm/qgit/qgit4.git
6c4444edbc4b870df7cde1e05ee76d1d15ea428f        HEAD
6c4444edbc4b870df7cde1e05ee76d1d15ea428f        refs/heads/master
70cd59500e8113901333741d82bbd055f96787f6        refs/tags/qgit-2.0rc1
1fe8ecc6a47d47a883beab1afa4607b1ca5da698        refs/tags/qgit-2.0rc1^{}
29bb10bf0397924489a51adb759f2df4b17fc31f        refs/tags/qgit-2.0rc2
243cd78b72b1a4021d63829f62419f5483e70c7d        refs/tags/qgit-2pre1
738063eb6f0f8f706e5f8609eab003ab19628617        refs/tags/qgit-2pre1^{}
17245c4248feab0d0425355ab5ff1cd4d7f83872        refs/tags/qgit2-pre2
7e02b07bc910a1d49b2cb4846641e01b7f6512aa        refs/tags/qgit2-pre2^{}

-- 
Sebastian Schuberth

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

[Sebastian Schuberth]

>>>  100% (2295/2295) done
>>> Resolving 1793 deltas...
>>>  100% (1793/1793) done
>>> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f
>>> fatal: Not a valid object name HEAD

As Mark Levedahl assumed by e-mail, the problem is with Cygwin's binary 
vs. text mount mode feature. Thanks Mark.

I'm running on NTFS and I did try the "binary mount" stuff before "git 
clone" by issuing

mount -bc /cygdrive

but I overlooked that this command only affects /cygdrive paths, and I 
did clone into a non /cygdrive path. So cloning to a /cygdrive mounted 
path works now.

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.

-- 
Sebastian Schuberth

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

[Shawn O. Pearce]

Sebastian Schuberth <sschuberth@gmail.com> wrote:
> 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.

Actually we never use fopen() when we care about the data (and we
always care about object data and working tree data).  We always
use open(2) and use system call IO directly to perform all reads
and writes.  fopen() is only used on trivial things, like say the
.git/config file.

Now on a normal UNIX system open(2) *always* by definition does
binary IO.  But Cygwin's text mount option tries to make UNIX
programs DOS-friendly by making all files treated as text, even if
it supposedly doing binary IO via open(2).

I think its a mis-feature of Cygwin.  Git has no way (that I know
of) to defend itself from this, other than to tell the user to make
sure they only store a Git repository in a location that is mounted
with the binary flag.

-- 
Shawn.

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

[Brian Downing]

On Tue, Aug 07, 2007 at 10:36:16AM -0400, Shawn O. Pearce wrote:
> Now on a normal UNIX system open(2) *always* by definition does
> binary IO.  But Cygwin's text mount option tries to make UNIX
> programs DOS-friendly by making all files treated as text, even if
> it supposedly doing binary IO via open(2).
> 
> I think its a mis-feature of Cygwin.  Git has no way (that I know
> of) to defend itself from this, other than to tell the user to make
> sure they only store a Git repository in a location that is mounted
> with the binary flag.

Cygwin, like Windows' own open(2) simulation, defines an O_BINARY to pass
as a flag to open(2).  I once got Git half-working on Cygwin text-mode
mounts by doing a horrible hack approximating:

#define open(name, flag, ...) \
	open(name, (flag) | O_BINARY, ## __VA_ARGS__)

But it only half worked.  Eventually it managed to corrupt itself again,
and worse, the test suite was completely hopeless, as all shell activity
still results in text-mode files.

-bcd

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

[Sebastian Schuberth]

>> Now on a normal UNIX system open(2) *always* by definition does
>> binary IO.  But Cygwin's text mount option tries to make UNIX
>> programs DOS-friendly by making all files treated as text, even if
>> it supposedly doing binary IO via open(2).
>>
>> I think its a mis-feature of Cygwin.  Git has no way (that I know
>> of) to defend itself from this, other than to tell the user to make
>> sure they only store a Git repository in a location that is mounted
>> with the binary flag.
> 
> Cygwin, like Windows' own open(2) simulation, defines an O_BINARY to pass
> as a flag to open(2).  I once got Git half-working on Cygwin text-mode
> mounts by doing a horrible hack approximating:
> 
> #define open(name, flag, ...) \
> 	open(name, (flag) | O_BINARY, ## __VA_ARGS__)
> 
> But it only half worked.  Eventually it managed to corrupt itself again,
> and worse, the test suite was completely hopeless, as all shell activity
> still results in text-mode files.

Something like that would have been my suggested work-around, too. 
Unfortunate to hear this alone won't fix the problem. I've spotted 
several fopen() calls in git where "b" is not explicitly used. Maybe 
fixing those, too, would to do it.

-- 
Sebastian Schuberth

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

[Mark Levedahl]

On 8/7/07, Sebastian Schuberth <sschuberth@gmail.com> 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

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

[Steffen Prohaska]

On Aug 7, 2007, at 4:58 PM, Brian Downing wrote:

> But it only half worked.  Eventually it managed to corrupt itself  
> again,
> and worse, the test suite was completely hopeless, as all shell  
> activity
> still results in text-mode files.

Why that? Although I don't fully understand the description
of the (no)binmode CYGWIN environment variable option [1], it
sound to me as if shells might do the right thing by default.

But wait ... further down in the document there's more magic.
(no)tty might be related as well.

My question is, is there any chance to handle the shell
activity by setting the right CYGWIN options?


Here's another idea. Could git somehow check if the file
operations work as expected and if not refuse to work.
Git would at least have a well defined behaviour on cygwin,
independently of the weird binmode/textmode stuff. Either
it works, or it tells that it can't work.

Something like

fp = fopen ("tmp-test", "w"); /* no b */
fprintf (fp, "\n");
fclose (fp)

fp = fopen (tmp-test", "rb"); /* with b */
if (freads returns crap) die;

I checked a couple of cygwin installations on our machines
and the results are quite scary. Some have all binmode,
some have all textmode, and some have some parts mounted
as binmode and other as textmode. I'd not dare to recommend
using git on these machines.

	Steffen

[1] http://www.cygwin.com/cygwin-ug-net/using-cygwinenv.html

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

[Mark Levedahl]

On 8/7/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> My question is, is there any chance to handle the shell
> activity by setting the right CYGWIN options?
>

See my other message: text mounts are best considered obsolescent if
not deprecated, and that mode is definitely not actively developed.
There are just too many loopholes with forks and pipes to reliably "do
the right thing."

Your suggested tests for non-binary mode mounts (properly #ifdef'd for
Cygwin, possibly only enabled if specifically configured in) are a
reasonable idea.

Mark

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

[Steffen Prohaska]

[-- Attachment #1: Type: text/plain, Size: 2716 bytes --]

The discussion below basically leads to two questions:

Is there any chance that git can be ported to cygwin's textmode?

Is there any chance that patches would be accepted that try to
do so? Even if they add "b" to fopen and O_BINARY to open, which
both are useless on Unix?

Junio, Linus?

On Aug 7, 2007, at 7:42 PM, Mark Levedahl wrote:

> On 8/7/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> My question is, is there any chance to handle the shell
>> activity by setting the right CYGWIN options?
>>
>
> See my other message: text mounts are best considered obsolescent if
> not deprecated, and that mode is definitely not actively developed.
> There are just too many loopholes with forks and pipes to reliably "do
> the right thing."

I read your message and I just checked the most recent installer
of cygwin (screenshot attached).

I see three choices I'm offered:
1) the path to install;
2) install for all or just me;
3) choose the default text file type.

I wouldn't call that deprecated, not even obsolenscent. To me it
looks, as if the installer offers me a real choice. Besides the
default path (which I never changed) and the decision whether I install
for all (which I would always do) I see a single real choice in this
installer -- the text file type. That's far from deprecated. I am
strongly convinced that many consider to choose DOS/text if it offers
a benefit for them, for example if they want to run CVS in cygwin.

And if the option to choose is around today, a reasonable assumption
is that cygwin installations in textmode will be around for another
couple of years.

I was convinced that git supports Windows, at least in cygwin. I am
no longer convinced. I would no longer call this Windows support --
not even in cygwin. The first four people I asked to test git on
Windows came back to me and told me that something is broken. They
didn't do anything wrong. They just used an option that cygwin
offers them during installation -- not hidden, not deprecated, no
indication that they shouldn't use this option. They or someone else
may have made the choice years ago. Their first impression was: git
doesn't work. One of them is now testing Mercurial. He explained me
today: "well, git can't even clone its own development repo. I
recognized that Mercurial is basically doing the same and it's
working fine for me."

I'd really prefer if git handled textmode (or at least refuses to
work if it detects textmode).


> Your suggested tests for non-binary mode mounts (properly #ifdef'd for
> Cygwin, possibly only enabled if specifically configured in) are a
> reasonable idea.

We could try to restrict that to git commands that have not proved
to work with textmode.

	Steffen



[-- Attachment #2.1: cygwin.png --]
[-- Type: application/applefile, Size: 70 bytes --]

[-- Attachment #2.2: cygwin.png --]
[-- Type: image/png, Size: 21751 bytes --]

[-- Attachment #3: Type: text/plain, Size: 3 bytes --]

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

[Linus Torvalds]

On Tue, 7 Aug 2007, Steffen Prohaska wrote:
>
> Is there any chance that patches would be accepted that try to
> do so? Even if they add "b" to fopen and O_BINARY to open, which
> both are useless on Unix?

I certainly don't think it would be wrong to add O_BINARY to the open() 
parameters (and "b" to fopen() and friends), if it makes a difference.

Add a

	#ifndef O_BINARY
	#define O_BINARY 0
	#endif

and it should be harmless anywhere else.

So if you're willing to test, and extend on this, maybe something like 
this gets you started (I think the main issue will be the object files, 
no?)

		Linus
---
diff --git a/sha1_file.c b/sha1_file.c
index aca741b..0f613c0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -23,6 +23,10 @@
 #endif
 #endif
 
+#ifndef O_BINARY
+#define O_BINARY 0
+#endif
+
 #ifdef NO_C99_FORMAT
 #define SZ_FMT "lu"
 #else
@@ -444,7 +448,7 @@ static int check_packed_git_idx(const char *path,  struct packed_git *p)
 	struct pack_idx_header *hdr;
 	size_t idx_size;
 	uint32_t version, nr, i, *index;
-	int fd = open(path, O_RDONLY);
+	int fd = open(path, O_BINARY | O_RDONLY);
 	struct stat st;
 
 	if (fd < 0)
@@ -631,7 +635,7 @@ static int open_packed_git_1(struct packed_git *p)
 	if (!p->index_data && open_pack_index(p))
 		return error("packfile %s index unavailable", p->pack_name);
 
-	p->pack_fd = open(p->pack_name, O_RDONLY);
+	p->pack_fd = open(p->pack_name, O_BINARY | O_RDONLY);
 	if (p->pack_fd < 0 || fstat(p->pack_fd, &st))
 		return -1;
 
@@ -983,12 +987,12 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
 		return NULL;
 	}
 
-	fd = open(filename, O_RDONLY | sha1_file_open_flag);
+	fd = open(filename, O_BINARY | O_RDONLY | sha1_file_open_flag);
 	if (fd < 0) {
 		/* See if it works without O_NOATIME */
 		switch (sha1_file_open_flag) {
 		default:
-			fd = open(filename, O_RDONLY);
+			fd = open(filename, O_BINARY | O_RDONLY);
 			if (fd >= 0)
 				break;
 		/* Fallthrough */
@@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
 	return 0;
 }
 
+static void close_or_die(int fd, const char *file)
+{
+	if (close(fd))
+		die("unable to close %s (%s)", file, strerror(errno));
+}
+
 static int write_buffer(int fd, const void *buf, size_t len)
 {
 	if (write_in_full(fd, buf, len) < 0)
@@ -2059,7 +2069,7 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
 		hashcpy(returnsha1, sha1);
 	if (has_sha1_file(sha1))
 		return 0;
-	fd = open(filename, O_RDONLY);
+	fd = open(filename, O_BINARY | O_RDONLY);
 	if (fd >= 0) {
 		/*
 		 * FIXME!!! We might do collision checking here, but we'd
@@ -2112,11 +2122,9 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
 
 	size = stream.total_out;
 
-	if (write_buffer(fd, compressed, size) < 0)
-		die("unable to write sha1 file");
+	write_or_die(fd, compressed, size);
 	fchmod(fd, 0444);
-	if (close(fd))
-		die("unable to write sha1 file");
+	close_or_die(fd, "sha1 file");
 	free(compressed);
 
 	return move_temp_to_file(tmpfile, filename);
@@ -2229,8 +2237,7 @@ int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,
 				SHA1_Update(&c, discard, sizeof(discard) -
 					    stream.avail_out);
 			} while (stream.avail_in && ret == Z_OK);
-			if (write_buffer(local, buffer, *bufposn - stream.avail_in) < 0)
-				die("unable to write sha1 file");
+			write_or_die(local, buffer, *bufposn - stream.avail_in);
 			memmove(buffer, buffer + *bufposn - stream.avail_in,
 				stream.avail_in);
 			*bufposn = stream.avail_in;
@@ -2251,8 +2258,7 @@ int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,
 	inflateEnd(&stream);
 
 	fchmod(local, 0444);
-	if (close(local) != 0)
-		die("unable to write sha1 file");
+	close_or_die(local, "sha1 file");
 	SHA1_Final(real_sha1, &c);
 	if (ret != Z_STREAM_END) {
 		unlink(tmpfile);
@@ -2412,7 +2418,7 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write
 
 	switch (st->st_mode & S_IFMT) {
 	case S_IFREG:
-		fd = open(path, O_RDONLY);
+		fd = open(path, O_BINARY | O_RDONLY);
 		if (fd < 0)
 			return error("open(\"%s\"): %s", path,
 				     strerror(errno));

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

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> The discussion below basically leads to two questions:
>
> Is there any chance that git can be ported to cygwin's textmode?
>
> Is there any chance that patches would be accepted that try to
> do so? Even if they add "b" to fopen and O_BINARY to open, which
> both are useless on Unix?
>
> Junio, Linus?

Hopefully fopen() would not barf upon seeing "b", and O_BINARY
can be ifdefed to 0 on platforms where it is not applicable and
or'ed in to the flags.  As long as they can be proven to be
useful on Cygwin, I do not see an issue.

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, 7 Aug 2007, Steffen Prohaska wrote:
>>
>> Is there any chance that patches would be accepted that try to
>> do so? Even if they add "b" to fopen and O_BINARY to open, which
>> both are useless on Unix?
>
> I certainly don't think it would be wrong to add O_BINARY to the open() 
> parameters (and "b" to fopen() and friends), if it makes a difference.
>
> Add a
>
> 	#ifndef O_BINARY
> 	#define O_BINARY 0
> 	#endif
>
> and it should be harmless anywhere else.

Heh, you beat me to this ---  I like it.

> @@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
> ...
> +static void close_or_die(int fd, const char *file)
> +{
> +	if (close(fd))
> +		die("unable to close %s (%s)", file, strerror(errno));
> +}
> +

And I like this even better ;-).

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

[Steffen Prohaska]

On Aug 7, 2007, at 11:44 PM, Linus Torvalds wrote:

>
>
> On Tue, 7 Aug 2007, Steffen Prohaska wrote:
>>
>> Is there any chance that patches would be accepted that try to
>> do so? Even if they add "b" to fopen and O_BINARY to open, which
>> both are useless on Unix?
>
> I certainly don't think it would be wrong to add O_BINARY to the  
> open()
> parameters (and "b" to fopen() and friends), if it makes a difference.
>
> Add a
>
> 	#ifndef O_BINARY
> 	#define O_BINARY 0
> 	#endif
>
> and it should be harmless anywhere else.
>
> So if you're willing to test, and extend on this, maybe something like
> this gets you started (I think the main issue will be the object  
> files,
> no?)

I took a more radical approach and used a small script to add
"b" to all calls to fopen and O_BINARY to all calls to open.
O_BINARY is provided by the Makefile if not on cygwin. I don't
think we need to differentiate between binary and textfiles.
I'll send the patch shortly.


I started to run the tests on cygwin in textmode. I chose the
following setup.

- cygwin is set to binmode, that is cygwin's git is working.

- I used git to cloned git to a Windows directory, say c:\git
   and compiled there. The Windows directory is mounted in binmode.

- For testing I 'mount' this directory in text mode, in my example

     cd /
     mkdir git-textmode
     mount --text 'c:\git' git-textmode

This setup allows you to work with git and test in the same
working directory in textmode. You should double check in which
of your directories you commit. Right now, committing in the
textmode directory is only for the brave ones.
'git read-tree HEAD' in the binmode directory should help if
you executed the wrong git in the wrong directory and your index
got corrupted.


The first problems I ran into are pre-computed sha1's for the
test cases. I started to add d2u to the test scripts to generate
files with unix style line endings even if cygwin is in textmode.
This is needed to match the expected results that come with
the test files. I'll send the first changes in a second patch.
The patch is only for illustrating the problem. It's not thought
to be applied.

The tests are running. t0000-basic and t0010-racy-git pass. I'll
send a testlog later. It's running inside a virtual machine on a
laptop, so it may take some more time.

I suspect the tests will report a lot of errors. At least all
tests that compare 'echo' output with precomputed sha1's or
expected results that come with the tests should fail. I haven't
fully understood the details of line conversion of cygwin. Some
work may be needed to eliminate false fails from the tests, e.g. by
adding 'd2u', and find the real problems.

I have no time to continue today.

	Steffen

[PATCH] cygwin: added fopen "b" and open O_BINARY to support cygwin's textmode

[Steffen Prohaska]

O_BINARY = 0 is provided by the Makefile for all architectures
except Cygwin.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Makefile                |    5 +++++
 attr.c                  |    2 +-
 builtin-apply.c         |    8 ++++----
 builtin-blame.c         |    4 ++--
 builtin-bundle.c        |    4 ++--
 builtin-fetch--tool.c   |    4 ++--
 builtin-fmt-merge-msg.c |    2 +-
 builtin-fsck.c          |    2 +-
 builtin-grep.c          |    4 ++--
 builtin-init-db.c       |    4 ++--
 builtin-mailinfo.c      |    4 ++--
 builtin-mailsplit.c     |    6 +++---
 builtin-reflog.c        |    2 +-
 builtin-rerere.c        |   12 ++++++------
 combine-diff.c          |    2 +-
 commit.c                |    2 +-
 config.c                |    4 ++--
 daemon.c                |    4 ++--
 diff.c                  |    2 +-
 diffcore-order.c        |    2 +-
 dir.c                   |    2 +-
 entry.c                 |    2 +-
 fast-import.c           |    6 +++---
 hash-object.c           |    2 +-
 http-fetch.c            |    6 +++---
 http-push.c             |    6 +++---
 imap-send.c             |    2 +-
 index-pack.c            |    6 +++---
 local-fetch.c           |    6 +++---
 lockfile.c              |    2 +-
 mailmap.c               |    2 +-
 merge-recursive.c       |    4 ++--
 pack-write.c            |    2 +-
 path.c                  |    4 ++--
 read-cache.c            |    4 ++--
 refs.c                  |   14 +++++++-------
 remote.c                |    4 ++--
 run-command.c           |    2 +-
 server-info.c           |    6 +++---
 sha1_file.c             |   14 +++++++-------
 shallow.c               |    2 +-
 test-delta.c            |    6 +++---
 trace.c                 |    2 +-
 43 files changed, 95 insertions(+), 90 deletions(-)

I took a more radical approach and used a small script to add
"b" to all calls to fopen and O_BINARY to all calls to open.
I don't think we need to differentiate between binary and
textfiles. 

    Steffen

diff --git a/Makefile b/Makefile
index 2f3b9b2..0959032 100644
--- a/Makefile
+++ b/Makefile
@@ -427,6 +427,7 @@ ifeq ($(uname_O),Cygwin)
 	NEEDS_LIBICONV = YesPlease
 	NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
 	NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
+	NO_O_BINARY = YesPlease
 	# There are conflicting reports about this.
 	# On some boxes NO_MMAP is needed, and not so elsewhere.
 	# Try commenting this out if you suspect MMAP is more efficient
@@ -495,6 +496,10 @@ ifeq ($(uname_S),Darwin)
 	endif
 endif
 
+ifndef NO_O_BINARY
+BASIC_CFLAGS += -DO_BINARY=0
+endif
+
 ifdef NO_R_TO_GCC_LINKER
 	# Some gcc does not accept and pass -R to the linker to specify
 	# the runtime dynamic library path.
diff --git a/attr.c b/attr.c
index a071254..442e2a6 100644
--- a/attr.c
+++ b/attr.c
@@ -315,7 +315,7 @@ static struct attr_stack *read_attr_from_file(const char *path, int macro_ok)
 	int lineno = 0;
 
 	res = xcalloc(1, sizeof(*res));
-	fp = fopen(path, "r");
+	fp = fopen(path, "rb");
 	if (!fp)
 		return res;
 
diff --git a/builtin-apply.c b/builtin-apply.c
index 0a0b4a9..5eecb7f 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1467,7 +1467,7 @@ static int read_old_data(struct stat *st, const char *path, char **buf_p, unsign
 	case S_IFLNK:
 		return readlink(path, buf, size) != size;
 	case S_IFREG:
-		fd = open(path, O_RDONLY);
+		fd = open(path, O_BINARY | O_RDONLY);
 		if (fd < 0)
 			return error("unable to open %s", path);
 		got = 0;
@@ -2404,7 +2404,7 @@ static int try_create_file(const char *path, unsigned int mode, const char *buf,
 		 */
 		return symlink(buf, path);
 
-	fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);
+	fd = open(path, O_CREAT | O_EXCL | O_BINARY | O_WRONLY, (mode & 0100) ? 0777 : 0666);
 	if (fd < 0)
 		return -1;
 
@@ -2553,7 +2553,7 @@ static int write_out_one_reject(struct patch *patch)
 	memcpy(namebuf, patch->new_name, cnt);
 	memcpy(namebuf + cnt, ".rej", 5);
 
-	rej = fopen(namebuf, "w");
+	rej = fopen(namebuf, "wb");
 	if (!rej)
 		return error("cannot open %s: %s", namebuf, strerror(errno));
 
@@ -2866,7 +2866,7 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
 		if (0 < prefix_length)
 			arg = prefix_filename(prefix, prefix_length, arg);
 
-		fd = open(arg, O_RDONLY);
+		fd = open(arg, O_BINARY | O_RDONLY);
 		if (fd < 0)
 			usage(apply_usage);
 		read_stdin = 0;
diff --git a/builtin-blame.c b/builtin-blame.c
index 0519339..0e3b06a 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1727,7 +1727,7 @@ static int prepare_lines(struct scoreboard *sb)
  */
 static int read_ancestry(const char *graft_file)
 {
-	FILE *fp = fopen(graft_file, "r");
+	FILE *fp = fopen(graft_file, "rb");
 	char buf[1024];
 	if (!fp)
 		return -1;
@@ -2035,7 +2035,7 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
 		mode = canon_mode(st.st_mode);
 		switch (st.st_mode & S_IFMT) {
 		case S_IFREG:
-			fd = open(read_from, O_RDONLY);
+			fd = open(read_from, O_BINARY | O_RDONLY);
 			if (fd < 0)
 				die("cannot open %s", read_from);
 			if (read_in_full(fd, buf, fin_size) != fin_size)
diff --git a/builtin-bundle.c b/builtin-bundle.c
index 6ae5ab0..4d189f5 100644
--- a/builtin-bundle.c
+++ b/builtin-bundle.c
@@ -66,7 +66,7 @@ static int read_string(int fd, char *buffer, int size)
 /* returns an fd */
 static int read_header(const char *path, struct bundle_header *header) {
 	char buffer[1024];
-	int fd = open(path, O_RDONLY);
+	int fd = open(path, O_BINARY | O_RDONLY);
 
 	if (fd < 0)
 		return error("could not open '%s'", path);
@@ -209,7 +209,7 @@ static int create_bundle(struct bundle_header *header, const char *path,
 	struct child_process rls;
 
 	bundle_fd = (!strcmp(path, "-") ? 1 :
-			open(path, O_CREAT | O_EXCL | O_WRONLY, 0666));
+			open(path, O_CREAT | O_EXCL | O_BINARY | O_WRONLY, 0666));
 	if (bundle_fd < 0)
 		return error("Could not create '%s': %s", path, strerror(errno));
 
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index e2f8ede..bf0fd1f 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -539,7 +539,7 @@ int cmd_fetch__tool(int argc, const char **argv, const char *prefix)
 
 		if (argc != 8)
 			return error("append-fetch-head takes 6 args");
-		fp = fopen(git_path("FETCH_HEAD"), "a");
+		fp = fopen(git_path("FETCH_HEAD"), "ab");
 		result = append_fetch_head(fp, argv[2], argv[3],
 					   argv[4], argv[5],
 					   argv[6], !!argv[7][0],
@@ -553,7 +553,7 @@ int cmd_fetch__tool(int argc, const char **argv, const char *prefix)
 
 		if (argc != 5)
 			return error("fetch-native-store takes 3 args");
-		fp = fopen(git_path("FETCH_HEAD"), "a");
+		fp = fopen(git_path("FETCH_HEAD"), "ab");
 		result = fetch_native_store(fp, argv[2], argv[3], argv[4],
 					    verbose, force);
 		fclose(fp);
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index ae60fcc..079c2d8 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -265,7 +265,7 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
 				in = stdin;
 			else {
 				fclose(in);
-				in = fopen(argv[2], "r");
+				in = fopen(argv[2], "rb");
 				if (!in)
 					die("cannot open %s", argv[2]);
 			}
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 8d12287..335dd80 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -150,7 +150,7 @@ static void check_unreachable_object(struct object *obj)
 				error("Could not create lost-found");
 				return;
 			}
-			if (!(f = fopen(filename, "w")))
+			if (!(f = fopen(filename, "wb")))
 				die("Could not open %s", filename);
 			if (obj->type == OBJ_BLOB) {
 				enum object_type type;
diff --git a/builtin-grep.c b/builtin-grep.c
index e13cb31..b941b04 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -135,7 +135,7 @@ static int grep_file(struct grep_opt *opt, const char *filename)
 	if (!S_ISREG(st.st_mode))
 		return 0;
 	sz = xsize_t(st.st_size);
-	i = open(filename, O_RDONLY);
+	i = open(filename, O_BINARY | O_RDONLY);
 	if (i < 0)
 		goto err_ret;
 	data = xmalloc(sz + 1);
@@ -577,7 +577,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 			char buf[1024];
 			if (argc <= 1)
 				die(emsg_missing_argument, arg);
-			patterns = fopen(argv[1], "r");
+			patterns = fopen(argv[1], "rb");
 			if (!patterns)
 				die("'%s': %s", argv[1], strerror(errno));
 			while (fgets(buf, sizeof(buf), patterns)) {
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 0d9b1e0..f9e6622 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -33,9 +33,9 @@ static int copy_file(const char *dst, const char *src, int mode)
 	int fdi, fdo, status;
 
 	mode = (mode & 0111) ? 0777 : 0666;
-	if ((fdi = open(src, O_RDONLY)) < 0)
+	if ((fdi = open(src, O_BINARY | O_RDONLY)) < 0)
 		return fdi;
-	if ((fdo = open(dst, O_WRONLY | O_CREAT | O_EXCL, mode)) < 0) {
+	if ((fdo = open(dst, O_WRONLY | O_CREAT | O_BINARY | O_EXCL, mode)) < 0) {
 		close(fdi);
 		return fdo;
 	}
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index b558754..d462da1 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -905,12 +905,12 @@ static int mailinfo(FILE *in, FILE *out, int ks, const char *encoding,
 	fin = in;
 	fout = out;
 
-	cmitmsg = fopen(msg, "w");
+	cmitmsg = fopen(msg, "wb");
 	if (!cmitmsg) {
 		perror(msg);
 		return -1;
 	}
-	patchfile = fopen(patch, "w");
+	patchfile = fopen(patch, "wb");
 	if (!patchfile) {
 		perror(patch);
 		fclose(cmitmsg);
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 43fc373..c04e82e 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -61,7 +61,7 @@ static int split_one(FILE *mbox, const char *name, int allow_bare)
 	if (is_bare && !allow_bare)
 		goto corrupt;
 
-	fd = open(name, O_WRONLY | O_CREAT | O_EXCL, 0666);
+	fd = open(name, O_WRONLY | O_CREAT | O_BINARY | O_EXCL, 0666);
 	if (fd < 0)
 		die("cannot open output file %s", name);
 	output = fdopen(fd, "w");
@@ -135,7 +135,7 @@ static int split_maildir(const char *maildir, const char *dir,
 	for (i = 0; i < list.nr; i++) {
 		FILE *f;
 		snprintf(file, sizeof(file), "%s/%s", curdir, list.items[i].path);
-		f = fopen(file, "r");
+		f = fopen(file, "rb");
 		if (!f) {
 			error("cannot open mail %s (%s)", file, strerror(errno));
 			goto out;
@@ -165,7 +165,7 @@ static int split_mbox(const char *file, const char *dir, int allow_bare,
 	char name[PATH_MAX];
 	int ret = -1;
 
-	FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
+	FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "rb");
 	int file_done = 0;
 
 	if (!f) {
diff --git a/builtin-reflog.c b/builtin-reflog.c
index ce093ca..a6221c3 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -257,7 +257,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
 		goto finish;
 	if (!cmd->dry_run) {
 		newlog_path = xstrdup(git_path("logs/%s.lock", ref));
-		cb.newlog = fopen(newlog_path, "w");
+		cb.newlog = fopen(newlog_path, "wb");
 	}
 
 	cb.ref_commit = lookup_commit_reference_gently(sha1, 1);
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 29d057c..0fe2beb 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -27,7 +27,7 @@ static void read_rr(struct path_list *rr)
 {
 	unsigned char sha1[20];
 	char buf[PATH_MAX];
-	FILE *in = fopen(merge_rr_path, "r");
+	FILE *in = fopen(merge_rr_path, "rb");
 	if (!in)
 		return;
 	while (fread(buf, 40, 1, in) == 1) {
@@ -98,14 +98,14 @@ static int handle_file(const char *path,
 	int hunk = 0, hunk_no = 0;
 	struct buffer minus = { NULL, 0, 0 }, plus = { NULL, 0, 0 };
 	struct buffer *one = &minus, *two = &plus;
-	FILE *f = fopen(path, "r");
+	FILE *f = fopen(path, "rb");
 	FILE *out;
 
 	if (!f)
 		return error("Could not open %s", path);
 
 	if (output) {
-		out = fopen(output, "w");
+		out = fopen(output, "wb");
 		if (!out) {
 			fclose(f);
 			return error("Could not write %s", output);
@@ -201,7 +201,7 @@ static int merge(const char *name, const char *path)
 	ret = xdl_merge(&base, &cur, "", &other, "",
 			&xpp, XDL_MERGE_ZEALOUS, &result);
 	if (!ret) {
-		FILE *f = fopen(path, "w");
+		FILE *f = fopen(path, "wb");
 		if (!f)
 			return error("Could not write to %s", path);
 		fwrite(result.ptr, result.size, 1, f);
@@ -299,9 +299,9 @@ static int copy_file(const char *src, const char *dest)
 	char buffer[32768];
 	int count;
 
-	if (!(in = fopen(src, "r")))
+	if (!(in = fopen(src, "rb")))
 		return error("Could not open %s", src);
-	if (!(out = fopen(dest, "w")))
+	if (!(out = fopen(dest, "wb")))
 		return error("Could not open %s", dest);
 	while ((count = fread(buffer, 1, sizeof(buffer), in)))
 		fwrite(buffer, 1, count, out);
diff --git a/combine-diff.c b/combine-diff.c
index ef62234..cb37aea 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -694,7 +694,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
 			result[len] = 0;
 			elem->mode = canon_mode(st.st_mode);
 		}
-		else if (0 <= (fd = open(elem->path, O_RDONLY)) &&
+		else if (0 <= (fd = open(elem->path, O_BINARY | O_RDONLY)) &&
 			 !fstat(fd, &st)) {
 			size_t len = xsize_t(st.st_size);
 			size_t sz = 0;
diff --git a/commit.c b/commit.c
index dc5a064..7baa1e7 100644
--- a/commit.c
+++ b/commit.c
@@ -206,7 +206,7 @@ struct commit_graft *read_graft_line(char *buf, int len)
 
 int read_graft_file(const char *graft_file)
 {
-	FILE *fp = fopen(graft_file, "r");
+	FILE *fp = fopen(graft_file, "rb");
 	char buf[1024];
 	if (!fp)
 		return -1;
diff --git a/config.c b/config.c
index dd2de6e..818d444 100644
--- a/config.c
+++ b/config.c
@@ -433,7 +433,7 @@ int git_default_config(const char *var, const char *value)
 int git_config_from_file(config_fn_t fn, const char *filename)
 {
 	int ret;
-	FILE *f = fopen(filename, "r");
+	FILE *f = fopen(filename, "rb");
 
 	ret = -1;
 	if (f) {
@@ -784,7 +784,7 @@ int git_config_set_multivar(const char* key, const char* value,
 	/*
 	 * If .git/config does not exist yet, write a minimal version.
 	 */
-	in_fd = open(config_filename, O_RDONLY);
+	in_fd = open(config_filename, O_BINARY | O_RDONLY);
 	if ( in_fd < 0 ) {
 		free(store.key);
 
diff --git a/daemon.c b/daemon.c
index 9cf22fe..4d2e211 100644
--- a/daemon.c
+++ b/daemon.c
@@ -956,7 +956,7 @@ static int service_loop(int socknum, int *socklist)
 /* if any standard file descriptor is missing open it to /dev/null */
 static void sanitize_stdfds(void)
 {
-	int fd = open("/dev/null", O_RDWR, 0);
+	int fd = open("/dev/null", O_BINARY | O_RDWR, 0);
 	while (fd != -1 && fd < 2)
 		fd = dup(fd);
 	if (fd == -1)
@@ -985,7 +985,7 @@ static void daemonize(void)
 
 static void store_pid(const char *path)
 {
-	FILE *f = fopen(path, "w");
+	FILE *f = fopen(path, "wb");
 	if (!f)
 		die("cannot open pid file %s: %s", path, strerror(errno));
 	if (fprintf(f, "%d\n", getpid()) < 0 || fclose(f) != 0)
diff --git a/diff.c b/diff.c
index a5fc56b..2521bad 100644
--- a/diff.c
+++ b/diff.c
@@ -1638,7 +1638,7 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
 			}
 			return 0;
 		}
-		fd = open(s->path, O_RDONLY);
+		fd = open(s->path, O_BINARY | O_RDONLY);
 		if (fd < 0)
 			goto err_empty;
 		s->data = xmmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
diff --git a/diffcore-order.c b/diffcore-order.c
index 2a4bd82..c08226d 100644
--- a/diffcore-order.c
+++ b/diffcore-order.c
@@ -19,7 +19,7 @@ static void prepare_order(const char *orderfile)
 	if (order)
 		return;
 
-	fd = open(orderfile, O_RDONLY);
+	fd = open(orderfile, O_BINARY | O_RDONLY);
 	if (fd < 0)
 		return;
 	if (fstat(fd, &st)) {
diff --git a/dir.c b/dir.c
index eb6c3ab..559f728 100644
--- a/dir.c
+++ b/dir.c
@@ -144,7 +144,7 @@ static int add_excludes_from_file_1(const char *fname,
 	size_t size;
 	char *buf, *entry;
 
-	fd = open(fname, O_RDONLY);
+	fd = open(fname, O_BINARY | O_RDONLY);
 	if (fd < 0 || fstat(fd, &st) < 0)
 		goto err;
 	size = xsize_t(st.st_size);
diff --git a/entry.c b/entry.c
index 0625112..02696d6 100644
--- a/entry.c
+++ b/entry.c
@@ -82,7 +82,7 @@ static void remove_subtree(const char *path)
 static int create_file(const char *path, unsigned int mode)
 {
 	mode = (mode & 0100) ? 0777 : 0666;
-	return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
+	return open(path, O_WRONLY | O_CREAT | O_BINARY | O_EXCL, mode);
 }
 
 static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned long *size)
diff --git a/fast-import.c b/fast-import.c
index 99a19d8..741ca41 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -757,7 +757,7 @@ static char *keep_pack(char *curr_index_name)
 
 	snprintf(name, sizeof(name), "%s/pack/pack-%s.keep",
 		 get_object_directory(), sha1_to_hex(pack_data->sha1));
-	keep_fd = open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
+	keep_fd = open(name, O_RDWR|O_CREAT|O_BINARY | O_EXCL, 0600);
 	if (keep_fd < 0)
 		die("cannot create keep file");
 	write(keep_fd, keep_msg, strlen(keep_msg));
@@ -2109,7 +2109,7 @@ static void cmd_checkpoint(void)
 static void import_marks(const char *input_file)
 {
 	char line[512];
-	FILE *f = fopen(input_file, "r");
+	FILE *f = fopen(input_file, "rb");
 	if (!f)
 		die("cannot read %s: %s", input_file, strerror(errno));
 	while (fgets(line, sizeof(line), f)) {
@@ -2185,7 +2185,7 @@ int main(int argc, const char **argv)
 		else if (!prefixcmp(a, "--export-pack-edges=")) {
 			if (pack_edges)
 				fclose(pack_edges);
-			pack_edges = fopen(a + 20, "a");
+			pack_edges = fopen(a + 20, "ab");
 			if (!pack_edges)
 				die("Cannot open %s: %s", a + 20, strerror(errno));
 		} else if (!strcmp(a, "--force"))
diff --git a/hash-object.c b/hash-object.c
index 18f5017..bb0621c 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -12,7 +12,7 @@ static void hash_object(const char *path, enum object_type type, int write_objec
 	int fd;
 	struct stat st;
 	unsigned char sha1[20];
-	fd = open(path, O_RDONLY);
+	fd = open(path, O_BINARY | O_RDONLY);
 	if (fd < 0 ||
 	    fstat(fd, &st) < 0 ||
 	    index_fd(sha1, fd, &st, write_object, type, path))
diff --git a/http-fetch.c b/http-fetch.c
index 202fae0..3a73acf 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -171,7 +171,7 @@ static void start_object_request(struct object_request *obj_req)
 
 	/* If a previous temp file is present, process what was already
 	   fetched. */
-	prevlocal = open(prevfile, O_RDONLY);
+	prevlocal = open(prevfile, O_BINARY | O_RDONLY);
 	if (prevlocal != -1) {
 		do {
 			prev_read = xread(prevlocal, prev_buf, PREV_BUF_SIZE);
@@ -403,7 +403,7 @@ static int fetch_index(struct alt_base *repo, unsigned char *sha1)
 
 	filename = sha1_pack_index_name(sha1);
 	snprintf(tmpfile, sizeof(tmpfile), "%s.temp", filename);
-	indexfile = fopen(tmpfile, "a");
+	indexfile = fopen(tmpfile, "ab");
 	if (!indexfile)
 		return error("Unable to open local file %s for pack index",
 			     filename);
@@ -763,7 +763,7 @@ static int fetch_pack(struct alt_base *repo, unsigned char *sha1)
 
 	filename = sha1_pack_name(target->sha1);
 	snprintf(tmpfile, sizeof(tmpfile), "%s.temp", filename);
-	packfile = fopen(tmpfile, "a");
+	packfile = fopen(tmpfile, "ab");
 	if (!packfile)
 		return error("Unable to open local file %s for pack",
 			     filename);
diff --git a/http-push.c b/http-push.c
index 7c3720f..921960f 100644
--- a/http-push.c
+++ b/http-push.c
@@ -286,7 +286,7 @@ static void start_fetch_loose(struct transfer_request *request)
 
 	/* If a previous temp file is present, process what was already
 	   fetched. */
-	prevlocal = open(prevfile, O_RDONLY);
+	prevlocal = open(prevfile, O_BINARY | O_RDONLY);
 	if (prevlocal != -1) {
 		do {
 			prev_read = xread(prevlocal, prev_buf, PREV_BUF_SIZE);
@@ -430,7 +430,7 @@ static void start_fetch_packed(struct transfer_request *request)
 		check_request = check_request->next;
 	}
 
-	packfile = fopen(request->tmpfile, "a");
+	packfile = fopen(request->tmpfile, "ab");
 	if (!packfile) {
 		fprintf(stderr, "Unable to open local file %s for pack",
 			filename);
@@ -949,7 +949,7 @@ static int fetch_index(unsigned char *sha1)
 
 	filename = sha1_pack_index_name(sha1);
 	snprintf(tmpfile, sizeof(tmpfile), "%s.temp", filename);
-	indexfile = fopen(tmpfile, "a");
+	indexfile = fopen(tmpfile, "ab");
 	if (!indexfile)
 		return error("Unable to open local file %s for pack index",
 			     filename);
diff --git a/imap-send.c b/imap-send.c
index a5a0696..1aab483 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -386,7 +386,7 @@ arc4_init( void )
 	int i, fd;
 	unsigned char j, si, dat[128];
 
-	if ((fd = open( "/dev/urandom", O_RDONLY )) < 0 && (fd = open( "/dev/random", O_RDONLY )) < 0) {
+	if ((fd = open( "/dev/urandom", O_RDONLY )) < 0 && (fd = open( "/dev/random", O_BINARY | O_RDONLY )) < 0) {
 		fprintf( stderr, "Fatal: no random number source available.\n" );
 		exit( 3 );
 	}
diff --git a/index-pack.c b/index-pack.c
index 8403c36..f6e65a4 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -117,12 +117,12 @@ static const char *open_pack_file(const char *pack_name)
 			output_fd = mkstemp(tmpfile);
 			pack_name = xstrdup(tmpfile);
 		} else
-			output_fd = open(pack_name, O_CREAT|O_EXCL|O_RDWR, 0600);
+			output_fd = open(pack_name, O_CREAT|O_EXCL|O_BINARY | O_RDWR, 0600);
 		if (output_fd < 0)
 			die("unable to create %s: %s\n", pack_name, strerror(errno));
 		pack_fd = output_fd;
 	} else {
-		input_fd = open(pack_name, O_RDONLY);
+		input_fd = open(pack_name, O_BINARY | O_RDONLY);
 		if (input_fd < 0)
 			die("cannot open packfile '%s': %s",
 			    pack_name, strerror(errno));
@@ -625,7 +625,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
 				 get_object_directory(), sha1_to_hex(sha1));
 			keep_name = name;
 		}
-		keep_fd = open(keep_name, O_RDWR|O_CREAT|O_EXCL, 0600);
+		keep_fd = open(keep_name, O_RDWR|O_CREAT|O_BINARY | O_EXCL, 0600);
 		if (keep_fd < 0) {
 			if (errno != EEXIST)
 				die("cannot write keep file");
diff --git a/local-fetch.c b/local-fetch.c
index bf7ec6c..deac558 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -85,13 +85,13 @@ static int copy_file(const char *source, char *dest, const char *hex,
 	if (use_filecopy) {
 		int ifd, ofd, status = 0;
 
-		ifd = open(source, O_RDONLY);
+		ifd = open(source, O_BINARY | O_RDONLY);
 		if (ifd < 0) {
 			if (!warn_if_not_exists && errno == ENOENT)
 				return -1;
 			return error("cannot open %s", source);
 		}
-		ofd = open(dest, O_WRONLY | O_CREAT | O_EXCL, 0666);
+		ofd = open(dest, O_WRONLY | O_CREAT | O_BINARY | O_EXCL, 0666);
 		if (ofd < 0) {
 			close(ifd);
 			return error("cannot open %s", dest);
@@ -173,7 +173,7 @@ int fetch_ref(char *ref, unsigned char *sha1)
 		ref_name_start = strlen(filename);
 	}
 	strcpy(filename + ref_name_start, ref);
-	ifd = open(filename, O_RDONLY);
+	ifd = open(filename, O_BINARY | O_RDONLY);
 	if (ifd < 0) {
 		close(ifd);
 		return error("cannot open %s", filename);
diff --git a/lockfile.c b/lockfile.c
index 9a1f64d..680c2fd 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -130,7 +130,7 @@ static int lock_file(struct lock_file *lk, const char *path)
 	 */
 	resolve_symlink(lk->filename, sizeof(lk->filename)-5);
 	strcat(lk->filename, ".lock");
-	fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
+	fd = open(lk->filename, O_RDWR | O_CREAT | O_BINARY | O_EXCL, 0666);
 	if (0 <= fd) {
 		if (!lock_file_list) {
 			signal(SIGINT, remove_lock_file_on_signal);
diff --git a/mailmap.c b/mailmap.c
index 8714167..685dd9d 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -5,7 +5,7 @@
 int read_mailmap(struct path_list *map, const char *filename, char **repo_abbrev)
 {
 	char buffer[1024];
-	FILE *f = fopen(filename, "r");
+	FILE *f = fopen(filename, "rb");
 
 	if (f == NULL)
 		return 1;
diff --git a/merge-recursive.c b/merge-recursive.c
index c8539ec..2d44d89 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -590,7 +590,7 @@ static void update_file_flags(const unsigned char *sha,
 				mode = 0777;
 			else
 				mode = 0666;
-			fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
+			fd = open(path, O_WRONLY | O_TRUNC | O_BINARY | O_CREAT, mode);
 			if (fd < 0)
 				die("failed to open %s: %s", path, strerror(errno));
 			flush_buffer(fd, buf, size);
@@ -831,7 +831,7 @@ static int ll_ext_merge(const struct ll_merge_driver *fn,
 		; /* failure in run-command */
 	else
 		status = -status;
-	fd = open(temp[1], O_RDONLY);
+	fd = open(temp[1], O_BINARY | O_RDONLY);
 	if (fd < 0)
 		goto bad;
 	if (fstat(fd, &st))
diff --git a/pack-write.c b/pack-write.c
index 1cf5f7c..9abbd33 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -49,7 +49,7 @@ const char *write_idx_file(const char *index_name, struct pack_idx_entry **objec
 		index_name = xstrdup(tmpfile);
 	} else {
 		unlink(index_name);
-		fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);
+		fd = open(index_name, O_CREAT|O_EXCL|O_BINARY | O_WRONLY, 0600);
 	}
 	if (fd < 0)
 		die("unable to create %s: %s", index_name, strerror(errno));
diff --git a/path.c b/path.c
index 4260952..7707729 100644
--- a/path.c
+++ b/path.c
@@ -6,7 +6,7 @@
  * It's obviously not thread-safe. Sue me. But it's quite
  * useful for doing things like
  *
- *   f = open(mkpath("%s/%s.git", base, name), O_RDONLY);
+ *   f = open(mkpath("%s/%s.git", base, name), O_BINARY | O_RDONLY);
  *
  * which is what it's designed for.
  */
@@ -107,7 +107,7 @@ int validate_headref(const char *path)
 	/*
 	 * Anything else, just open it and try to see if it is a symbolic ref.
 	 */
-	fd = open(path, O_RDONLY);
+	fd = open(path, O_BINARY | O_RDONLY);
 	if (fd < 0)
 		return -1;
 	len = read_in_full(fd, buffer, sizeof(buffer)-1);
diff --git a/read-cache.c b/read-cache.c
index e060392..659b1ef 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -48,7 +48,7 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
 static int ce_compare_data(struct cache_entry *ce, struct stat *st)
 {
 	int match = -1;
-	int fd = open(ce->name, O_RDONLY);
+	int fd = open(ce->name, O_BINARY | O_RDONLY);
 
 	if (fd >= 0) {
 		unsigned char sha1[20];
@@ -894,7 +894,7 @@ int read_index_from(struct index_state *istate, const char *path)
 
 	errno = ENOENT;
 	istate->timestamp = 0;
-	fd = open(path, O_RDONLY);
+	fd = open(path, O_BINARY | O_RDONLY);
 	if (fd < 0) {
 		if (errno == ENOENT)
 			return 0;
diff --git a/refs.c b/refs.c
index fac6548..5d1937f 100644
--- a/refs.c
+++ b/refs.c
@@ -216,7 +216,7 @@ static void read_packed_refs(FILE *f, struct cached_refs *cached_refs)
 static struct ref_list *get_packed_refs(void)
 {
 	if (!cached_refs.did_packed) {
-		FILE *f = fopen(git_path("packed-refs"), "r");
+		FILE *f = fopen(git_path("packed-refs"), "rb");
 		cached_refs.packed = NULL;
 		if (f) {
 			read_packed_refs(f, &cached_refs);
@@ -293,7 +293,7 @@ static int resolve_gitlink_packed_ref(char *name, int pathlen, const char *refna
 	int retval;
 
 	strcpy(name + pathlen, "packed-refs");
-	f = fopen(name, "r");
+	f = fopen(name, "rb");
 	if (!f)
 		return -1;
 	read_packed_refs(f, &refs);
@@ -320,7 +320,7 @@ static int resolve_gitlink_ref_recursive(char *name, int pathlen, const char *re
 	if (recursion > MAXDEPTH || len > MAXREFLEN)
 		return -1;
 	memcpy(name + pathlen, refname, len+1);
-	fd = open(name, O_RDONLY);
+	fd = open(name, O_BINARY | O_RDONLY);
 	if (fd < 0)
 		return resolve_gitlink_packed_ref(name, pathlen, refname, result);
 
@@ -429,7 +429,7 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
 		 * Anything else, just open it and try to use it as
 		 * a ref
 		 */
-		fd = open(path, O_RDONLY);
+		fd = open(path, O_BINARY | O_RDONLY);
 		if (fd < 0)
 			return NULL;
 		len = read_in_full(fd, buffer, sizeof(buffer)-1);
@@ -1209,7 +1209,7 @@ int create_symref(const char *ref_target, const char *refs_heads_master,
 		goto error_free_return;
 	}
 	lockpath = mkpath("%s.lock", git_HEAD);
-	fd = open(lockpath, O_CREAT | O_EXCL | O_WRONLY, 0666);
+	fd = open(lockpath, O_CREAT | O_EXCL | O_BINARY | O_WRONLY, 0666);
 	if (fd < 0) {
 		error("Unable to open %s for writing", lockpath);
 		goto error_free_return;
@@ -1268,7 +1268,7 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
 	size_t mapsz;
 
 	logfile = git_path("logs/%s", ref);
-	logfd = open(logfile, O_RDONLY, 0);
+	logfd = open(logfile, O_BINARY | O_RDONLY, 0);
 	if (logfd < 0)
 		die("Unable to read log %s: %s", logfile, strerror(errno));
 	fstat(logfd, &st);
@@ -1366,7 +1366,7 @@ int for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data)
 	int ret = 0;
 
 	logfile = git_path("logs/%s", ref);
-	logfp = fopen(logfile, "r");
+	logfp = fopen(logfile, "rb");
 	if (!logfp)
 		return -1;
 	while (fgets(buf, sizeof(buf), logfp)) {
diff --git a/remote.c b/remote.c
index bb774d0..f7c1644 100644
--- a/remote.c
+++ b/remote.c
@@ -69,7 +69,7 @@ static struct remote *make_remote(const char *name, int len)
 
 static void read_remotes_file(struct remote *remote)
 {
-	FILE *f = fopen(git_path("remotes/%s", remote->name), "r");
+	FILE *f = fopen(git_path("remotes/%s", remote->name), "rb");
 
 	if (!f)
 		return;
@@ -117,7 +117,7 @@ static void read_branches_file(struct remote *remote)
 {
 	const char *slash = strchr(remote->name, '/');
 	int n = slash ? slash - remote->name : 1000;
-	FILE *f = fopen(git_path("branches/%.*s", n, remote->name), "r");
+	FILE *f = fopen(git_path("branches/%.*s", n, remote->name), "rb");
 	char *s, *p;
 	int len;
 
diff --git a/run-command.c b/run-command.c
index 7e779d3..72c47d3 100644
--- a/run-command.c
+++ b/run-command.c
@@ -10,7 +10,7 @@ static inline void close_pair(int fd[2])
 
 static inline void dup_devnull(int to)
 {
-	int fd = open("/dev/null", O_RDWR);
+	int fd = open("/dev/null", O_BINARY | O_RDWR);
 	dup2(fd, to);
 	close(fd);
 }
diff --git a/server-info.c b/server-info.c
index 0d1312c..a096025 100644
--- a/server-info.c
+++ b/server-info.c
@@ -33,7 +33,7 @@ static int update_info_refs(int force)
 	strcpy(path1 + len, "+");
 
 	safe_create_leading_directories(path0);
-	info_ref_fp = fopen(path1, "w");
+	info_ref_fp = fopen(path1, "wb");
 	if (!info_ref_fp)
 		return error("unable to update %s", path0);
 	for_each_ref(add_info_ref, NULL);
@@ -95,7 +95,7 @@ static int read_pack_info_file(const char *infofile)
 	char line[1000];
 	int old_cnt = 0;
 
-	fp = fopen(infofile, "r");
+	fp = fopen(infofile, "rb");
 	if (!fp)
 		return 1; /* nonexistent is not an error. */
 
@@ -223,7 +223,7 @@ static int update_info_packs(int force)
 	init_pack_info(infofile, force);
 
 	safe_create_leading_directories(name);
-	fp = fopen(name, "w");
+	fp = fopen(name, "wb");
 	if (!fp)
 		return error("cannot open %s", name);
 	write_pack_info_file(fp);
diff --git a/sha1_file.c b/sha1_file.c
index aca741b..9866aa9 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -360,7 +360,7 @@ static void read_info_alternates(const char * relative_base, int depth)
 	int fd;
 
 	sprintf(path, "%s/%s", relative_base, alt_file_name);
-	fd = open(path, O_RDONLY);
+	fd = open(path, O_BINARY | O_RDONLY);
 	if (fd < 0)
 		return;
 	if (fstat(fd, &st) || (st.st_size == 0)) {
@@ -444,7 +444,7 @@ static int check_packed_git_idx(const char *path,  struct packed_git *p)
 	struct pack_idx_header *hdr;
 	size_t idx_size;
 	uint32_t version, nr, i, *index;
-	int fd = open(path, O_RDONLY);
+	int fd = open(path, O_BINARY | O_RDONLY);
 	struct stat st;
 
 	if (fd < 0)
@@ -631,7 +631,7 @@ static int open_packed_git_1(struct packed_git *p)
 	if (!p->index_data && open_pack_index(p))
 		return error("packfile %s index unavailable", p->pack_name);
 
-	p->pack_fd = open(p->pack_name, O_RDONLY);
+	p->pack_fd = open(p->pack_name, O_BINARY | O_RDONLY);
 	if (p->pack_fd < 0 || fstat(p->pack_fd, &st))
 		return -1;
 
@@ -983,12 +983,12 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
 		return NULL;
 	}
 
-	fd = open(filename, O_RDONLY | sha1_file_open_flag);
+	fd = open(filename, O_BINARY | O_RDONLY | sha1_file_open_flag);
 	if (fd < 0) {
 		/* See if it works without O_NOATIME */
 		switch (sha1_file_open_flag) {
 		default:
-			fd = open(filename, O_RDONLY);
+			fd = open(filename, O_BINARY | O_RDONLY);
 			if (fd >= 0)
 				break;
 		/* Fallthrough */
@@ -2059,7 +2059,7 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
 		hashcpy(returnsha1, sha1);
 	if (has_sha1_file(sha1))
 		return 0;
-	fd = open(filename, O_RDONLY);
+	fd = open(filename, O_BINARY | O_RDONLY);
 	if (fd >= 0) {
 		/*
 		 * FIXME!!! We might do collision checking here, but we'd
@@ -2412,7 +2412,7 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write
 
 	switch (st->st_mode & S_IFMT) {
 	case S_IFREG:
-		fd = open(path, O_RDONLY);
+		fd = open(path, O_BINARY | O_RDONLY);
 		if (fd < 0)
 			return error("open(\"%s\"): %s", path,
 				     strerror(errno));
diff --git a/shallow.c b/shallow.c
index dbd9f5a..b31020b 100644
--- a/shallow.c
+++ b/shallow.c
@@ -25,7 +25,7 @@ int is_repository_shallow(void)
 	if (is_shallow >= 0)
 		return is_shallow;
 
-	fp = fopen(git_path("shallow"), "r");
+	fp = fopen(git_path("shallow"), "rb");
 	if (!fp) {
 		is_shallow = 0;
 		return is_shallow;
diff --git a/test-delta.c b/test-delta.c
index 3d885ff..53011a4 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -27,7 +27,7 @@ int main(int argc, char *argv[])
 		return 1;
 	}
 
-	fd = open(argv[2], O_RDONLY);
+	fd = open(argv[2], O_BINARY | O_RDONLY);
 	if (fd < 0 || fstat(fd, &st)) {
 		perror(argv[2]);
 		return 1;
@@ -41,7 +41,7 @@ int main(int argc, char *argv[])
 	}
 	close(fd);
 
-	fd = open(argv[3], O_RDONLY);
+	fd = open(argv[3], O_BINARY | O_RDONLY);
 	if (fd < 0 || fstat(fd, &st)) {
 		perror(argv[3]);
 		return 1;
@@ -68,7 +68,7 @@ int main(int argc, char *argv[])
 		return 1;
 	}
 
-	fd = open (argv[4], O_WRONLY|O_CREAT|O_TRUNC, 0666);
+	fd = open (argv[4], O_WRONLY|O_CREAT|O_BINARY | O_TRUNC, 0666);
 	if (fd < 0 || write_in_full(fd, out_buf, out_size) != out_size) {
 		perror(argv[4]);
 		return 1;
diff --git a/trace.c b/trace.c
index 7961a27..b8c6a44 100644
--- a/trace.c
+++ b/trace.c
@@ -65,7 +65,7 @@ static int get_trace_fd(int *need_close)
 	if (strlen(trace) == 1 && isdigit(*trace))
 		return atoi(trace);
 	if (*trace == '/') {
-		int fd = open(trace, O_WRONLY | O_APPEND | O_CREAT, 0666);
+		int fd = open(trace, O_WRONLY | O_APPEND | O_BINARY | O_CREAT, 0666);
 		if (fd == -1) {
 			fprintf(stderr,
 				"Could not open '%s' for tracing: %s\n"
-- 
1.5.1.2

[PATCH] tests: added d2u to have unix style testfiles even in textmode

[Steffen Prohaska]

This is needed if the content of files is compared with
precomputed sha1s or stored expected results.

***WARNING***
This patch is useful for testing and illustrating the problem
but not thought to be applied to any official git branch.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 t/t0000-basic.sh      |    2 +-
 t/t0020-crlf.sh       |    8 ++++----
 t/t0021-conversion.sh |    4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 4e49d59..bf71ce6 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -91,7 +91,7 @@ test_expect_success \
 mkdir path2 path3 path3/subp3
 for p in path0 path2/file2 path3/file3 path3/subp3/file3
 do
-    echo "hello $p" >$p
+    echo "hello $p" | d2u >$p
     ln -s "hello $p" ${p}sym
 done
 test_expect_success \
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index fe1dfd0..52dc739 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -21,10 +21,10 @@ test_expect_success setup '
 
 	git repo-config core.autocrlf false &&
 
-	for w in Hello world how are you; do echo $w; done >one &&
+	for w in Hello world how are you; do echo $w; done | d2u >one &&
 	mkdir dir &&
-	for w in I am very very fine thank you; do echo $w; done >dir/two &&
-	for w in Oh here is NULQin text here; do echo $w; done | q_to_nul >three &&
+	for w in I am very very fine thank you; do echo $w; done | d2u  >dir/two &&
+	for w in Oh here is NULQin text here; do echo $w; done | q_to_nul | d2u >three &&
 	git add . &&
 
 	git commit -m initial &&
@@ -34,7 +34,7 @@ test_expect_success setup '
 	two=`git rev-parse HEAD:dir/two` &&
 	three=`git rev-parse HEAD:three` &&
 
-	for w in Some extra lines here; do echo $w; done >>one &&
+	for w in Some extra lines here; do echo $w; done | d2u >>one &&
 	git diff >patch.file &&
 	patched=`git hash-object --stdin <one` &&
 	git read-tree --reset -u HEAD &&
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index a839f4e..9ca11bb 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -57,7 +57,7 @@ test_expect_success expanded_in_repo '
 		echo "\$Id:NoSpaceAtFront \$"
 		echo "\$Id:NoSpaceAtEitherEnd\$"
 		echo "\$Id: NoTerminatingSymbol"
-	} > expanded-keywords &&
+	} | d2u > expanded-keywords &&
 
 	{
 		echo "File with expanded keywords"
@@ -68,7 +68,7 @@ test_expect_success expanded_in_repo '
 		echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
 		echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
 		echo "\$Id: NoTerminatingSymbol"
-	} > expected-output &&
+	} | d2u > expected-output &&
 
 	git add expanded-keywords &&
 	git commit -m "File with keywords expanded" &&
-- 
1.5.1.2

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

[Steffen Prohaska]

I apologize, I didn't check the size of the attachment
in the previous mail (which probably got blocked from
the list).

This time with a link to the logfile.


On Aug 8, 2007, at 12:46 AM, Steffen Prohaska wrote:

> The tests are running. t0000-basic and t0010-racy-git pass. I'll
> send a testlog later. It's running inside a virtual machine on a
> laptop, so it may take some more time.
>
> I suspect the tests will report a lot of errors. At least all
> tests that compare 'echo' output with precomputed sha1's or
> expected results that come with the tests should fail. I haven't
> fully understood the details of line conversion of cygwin. Some
> work may be needed to eliminate false fails from the tests, e.g. by
> adding 'd2u', and find the real problems.

I attached the log of a testrun on an textmode mounted directory
in cygwin with the two recently sent patches applied.

It doesn't look too bad, but it's far from perfect:

1470 ok to 637 FAIL

http://www.zib.de/prohaska/hidden/2007/git-cygwin-textmode/ 
testlog-2007-08-08.txt

	Steffen

Re: [PATCH] tests: added d2u to have unix style testfiles even in textmode

[Linus Torvalds]

On Wed, 8 Aug 2007, Steffen Prohaska wrote:
>
> This is needed if the content of files is compared with
> precomputed sha1s or stored expected results.
> 
> ***WARNING***
> This patch is useful for testing and illustrating the problem
> but not thought to be applied to any official git branch.

Quite frankly, *much* rather than having d2u everywhere, why not make the 
default for DOS/Windows be to have

	[core]
		autocrlf=true

and then none of this should hopefully be needed.

(We still need to write the internal git objects using O_BINARY to make 
sure that cygwin doesn't corrupt binary data, but that's a totally 
different issue).

			Linus

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

[Linus Torvalds]

On Tue, 7 Aug 2007, Junio C Hamano wrote:
> 
> > @@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
> > ...
> > +static void close_or_die(int fd, const char *file)
> > +{
> > +	if (close(fd))
> > +		die("unable to close %s (%s)", file, strerror(errno));
> > +}
> > +
> 
> And I like this even better ;-).

Gaah, that was unintentional. Just random noise I had in my tree, and 
didn't even realize made it into the patch.

That "close_or_die()" was because I saw somebody report a write error 
without the error string, apparently because the error only got reported 
on the close (probably NFS). This way you see if the reason the close 
failed was due to out of diskspace or whatever.

But I should have split them up properly - the close_or_die() part 
obviously had nothing to do with the O_BINARY part. Feel free to take it 
regardless, or split it yourself.

		Linus

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

[Brian Downing]

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().

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.

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.

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

-bcd

Re: [PATCH] tests: added d2u to have unix style testfiles even in textmode

[Steffen Prohaska]

On Aug 8, 2007, at 5:03 AM, Linus Torvalds wrote:

> On Wed, 8 Aug 2007, Steffen Prohaska wrote:
>>
>> This is needed if the content of files is compared with
>> precomputed sha1s or stored expected results.
>>
>> ***WARNING***
>> This patch is useful for testing and illustrating the problem
>> but not thought to be applied to any official git branch.
>
> Quite frankly, *much* rather than having d2u everywhere, why not  
> make the
> default for DOS/Windows be to have
>
> 	[core]
> 		autocrlf=true
>
> and then none of this should hopefully be needed.

Thanks for that idea. I'll check how far I can get with it.

	Steffen

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

[Steffen Prohaska]

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

> 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.

> 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?


> 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

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

[Sebastian Schuberth]

> Hopefully fopen() would not barf upon seeing "b", and O_BINARY
> can be ifdefed to 0 on platforms where it is not applicable and
> or'ed in to the flags.  As long as they can be proven to be
> useful on Cygwin, I do not see an issue.

According to

http://www.cygwin.com/faq/faq.api.html#faq.api.cr-lf

adding those flags should be okay:

"Note that because the open/fopen switches are defined by ANSI, they 
exist under most flavors of Unix; open/fopen will just ignore the switch 
since they have no meaning to UNIX."

-- 
Sebastian Schuberth

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

[Mark Levedahl]

On 8/7/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> I read your message and I just checked the most recent installer
> of cygwin (screenshot attached).
>
> I see three choices I'm offered:
> 1) the path to install;
> 2) install for all or just me;
> 3) choose the default text file type.
>
> I wouldn't call that deprecated, not even obsolenscent.

Call it passively deprecated. there has been a lot of discussion about
removing it, or at least hiding it behind the mount command and not
offering it at all during installation. The objective of text mounts
was noble, but it really is hard to automatically convert any
occurrence of crlf->lf and lf->crlf everywhere it should be done but
not where it should not be done. However, a lot of people use text
mounts without trouble (or at least without complaining to the lists),
so removing the option outright was thought too likely to cause an
uproar. So, consider that Cygwin is taking the "let it rot, remove it
later" approach. Anyone who has troubles is generally and not so
gently encouraged to just use binary mounts. There are some known crlf
problems, largely with bash/sh, pipes, forks, and redirection (of
which git is a heavy user so git is a prime candidate to get into
trouble) that are not being worked.

For instance, when working on git-bundle.sh, I got bit by crlf
conversions corrupting packfiles sent through a pipe on a system with
pure binary mounts and CYGWIN=binmode. The cure to that bug is
*removing* auto-crlf conversion from Cygwin.

Mark

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

[Steffen Prohaska]

On Aug 8, 2007, at 3:50 PM, Mark Levedahl wrote:

> On 8/7/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> I read your message and I just checked the most recent installer
>> of cygwin (screenshot attached).
>>
>> I see three choices I'm offered:
>> 1) the path to install;
>> 2) install for all or just me;
>> 3) choose the default text file type.
>>
>> I wouldn't call that deprecated, not even obsolenscent.
>
> Call it passively deprecated. there has been a lot of discussion about
> removing it, or at least hiding it behind the mount command and not
> offering it at all during installation. The objective of text mounts
> was noble, but it really is hard to automatically convert any
> occurrence of crlf->lf and lf->crlf everywhere it should be done but
> not where it should not be done. However, a lot of people use text
> mounts without trouble (or at least without complaining to the lists),
> so removing the option outright was thought too likely to cause an
> uproar.

That is what I'm facing now. A policy I need to handle tells
people explicitly to choose textmode to force cvs in cygwin to
do the right thing: converting lf->crlf->lf.

I'm not in a position to tell them not to follow this policy;
and I don't think it's reasonable to change the policy right away.
They have a lot of cvs working copies checked out and if they
switched from textmode to binmode now, they'd get crlf's on the
next commit, which they deliberately chose to avoid by using
textmode.


> So, consider that Cygwin is taking the "let it rot, remove it
> later" approach.

This may take years.

For me it would be easier if Cygwin (not I) told the world
very clearly: You must no longer use binary mounts. Consider
switching now, but you must switch until end of 2007. This
would make my life much more easier. I could tell that it's
not my fault and not git's fault, it's Cygwins decision to
drop support for textmode.

People might complain but I think they would understand.
Providing an option and letting people install software that is
not able to handle this option causes nothing but trouble. The
very least would be to only allow installing software that is
known to handle textmode. Or provide another mode that
guarantees that no conversion takes place and offers a larger
selection of packages.


> Anyone who has troubles is generally and not so
> gently encouraged to just use binary mounts. There are some known crlf
> problems, largely with bash/sh, pipes, forks, and redirection (of
> which git is a heavy user so git is a prime candidate to get into
> trouble) that are not being worked.
>
> For instance, when working on git-bundle.sh, I got bit by crlf
> conversions corrupting packfiles sent through a pipe on a system with
> pure binary mounts and CYGWIN=binmode. The cure to that bug is
> *removing* auto-crlf conversion from Cygwin.

Technically I agree. The problem is, textmode is not removed,
but appears as if it was supported (see installer).

I'm running out of options: git in cygwin appeared to work for
me, but it's not working in the context of the organization that
I need to deal with. I can't force them to switch to binary mode.
Other approaches to git on Windows are on their way, but, to my
understanding, are not mature enough. git-cvsserver doesn't provide
sufficient cvs functionality to be compatible with the needed
workflows.

The bottom line for me is, git does not yet support Windows in a
usable way for the organizations that I need to convince.

	Steffen

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

[Mark Levedahl]

On 8/8/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> The bottom line for me is, git does not yet support Windows in a
> usable way for the organizations that I need to convince.
>
>         Steffen
>

Have you considered jumping in to help on the msys git port Johannes
Schindelin is working? He has very generously offered to do
essentially everything except find bugs, the latter because he does
not actually use Windows so can't, and is clearly putting a great deal
of effort into this. A stable and complete Windows port may be much
closer than you think.

Mark

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

[Johannes Schindelin]

Hi,

On Wed, 8 Aug 2007, Mark Levedahl wrote:

> On 8/8/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >
> > The bottom line for me is, git does not yet support Windows in a
> > usable way for the organizations that I need to convince.
> >
> >         Steffen
> >
> 
> Have you considered jumping in to help on the msys git port Johannes
> Schindelin is working? He has very generously offered to do
> essentially everything except find bugs, the latter because he does
> not actually use Windows so can't, and is clearly putting a great deal
> of effort into this. A stable and complete Windows port may be much
> closer than you think.

To be fair, we are already a team of five working on it.  The 3rd 
generation of the net installer works as flawlessly as the first, but 
msysgit.git is a superproject now, containing the complete build 
environment you need, and has git/mingw/4msysgit.git as a submodule (yes, 
that is a fork of a fork; they work now on repo.or.cz).

Please find it on

	http://msysgit.googlecode.com/

(It's a meager 1.4 MB, so the whole rest is git-cloned natively!) It 
already passes all tests, is able to start gitk and git-gui, and more is 
to come!

And no, I did not agree to do _everything_.  I agreed to do things _when I 
get something in return_.

For example, we have a functional script sitting in msysgit.git which 
builds a complete WinGit installer (WinGit being the code name for "Git on 
MSys without the whole build environment").

It is incomplete in only a few issues:

	- it does not install anything in the start menu

	- it does not install any short cut on the Desktop

	- it does not install anything in the Quick Launch bar

	- it does not include a nice WelcomeToGit.html, to be launched 
	  after a successful install

	- it does not contain a nice way to start git-gui (you have to 
	  start it by hand from the command line inside bash)

	- etc.

So go for it, everybody, or alternatively do not even bother to whine.

Ciao,
Dscho

P.S.: I'll be not really available for a few days, starting from tomorrow, 
so do use the mailing list to keep in touch with others working on msysgit 
or 4msysgit, and do use the mob branch (you can bug the project members 
listed on the homepage to cherry-pick, sign off and push if need be).

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

[Steffen Prohaska]

On Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:

> On Wed, 8 Aug 2007, Mark Levedahl wrote:
>
>> On 8/8/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>>
>>> The bottom line for me is, git does not yet support Windows in a
>>> usable way for the organizations that I need to convince.
>>>
>>>         Steffen
>>>
>>
>> Have you considered jumping in to help on the msys git port Johannes
>> Schindelin is working? He has very generously offered to do
>> essentially everything except find bugs, the latter because he does
>> not actually use Windows so can't, and is clearly putting a great  
>> deal
>> of effort into this. A stable and complete Windows port may be much
>> closer than you think.
>

I'll look into it. However, my situation is similar to Johannes'. I do
not regularly work on Windows. I use my Mac for all office work and
typically code on Linux. However, I do use Windows from time to time
because the majority of the people I work with use Windows.

I have a real Windows running in a Virtual Machine and I consider
switching to it for a while, to see if things run smoothly. Here is
what I plan to do: I will set cygwin to textmode (!), although I know
better. But this is what most of the people I work with have. I'll
uninstall cygwin's git and install msysgit instead. I'll try to do
all the integration work, that is import from cvs on Linux, pull to
Windows and do coding and merges on Windows. I'll push back to Linux
and Mac for testing.

After the basic stuff, like pull, push, merge, commit, gitk, and
git gui, here's my first more difficult task: Will git-mergetool
launch something useful for me on Windows? I heard that WinDiff
would be useful. On Mac I use FileMerge.

> To be fair, we are already a team of five working on it.  The 3rd
> generation of the net installer works as flawlessly as the first, but
> msysgit.git is a superproject now, containing the complete build
> environment you need, and has git/mingw/4msysgit.git as a submodule  
> (yes,
> that is a fork of a fork; they work now on repo.or.cz).
>
> Please find it on
>
> 	http://msysgit.googlecode.com/
>
> (It's a meager 1.4 MB, so the whole rest is git-cloned natively!) It
> already passes all tests, is able to start gitk and git-gui, and  
> more is
> to come!
>
> And no, I did not agree to do _everything_.  I agreed to do things  
> _when I
> get something in return_.

I read this before. At the time you wrote about this on the mailing list
I thought that cygwin would be fine. I wasn't aware of the binmode/ 
textmode
magic and all the problems caused by it.

> For example, we have a functional script sitting in msysgit.git which
> builds a complete WinGit installer (WinGit being the code name for  
> "Git on
> MSys without the whole build environment").
>
> It is incomplete in only a few issues:
>
> 	- it does not install anything in the start menu
>
> 	- it does not install any short cut on the Desktop
>
> 	- it does not install anything in the Quick Launch bar
>
> 	- it does not include a nice WelcomeToGit.html, to be launched
> 	  after a successful install
>
> 	- it does not contain a nice way to start git-gui (you have to
> 	  start it by hand from the command line inside bash)
>
> 	- etc.
>
> So go for it, everybody, or alternatively do not even bother to whine.

I don't care about these things. I typically start the Explorer by  
typing
explorer into the 'Run ...' box of the start meny. So don't expect  
anything
from me that makes git more beautiful.

The only thing I want to achieve is a flawlessly running git that works
out-of-the box in the presence of a cygwin in textmode (!). If possible
git should have the same version number that I have on Linux and Mac,
which means the master branch of Junio's repo on my Mac. Lagging a bit
behind for a while is ok, but in general I'd prefer to have the same
version on Linux, Mac, and Windows. What I described means Windows  
support
for me. Having a nice installer is not important.

> Ciao,
> Dscho
>
> P.S.: I'll be not really available for a few days, starting from  
> tomorrow,
> so do use the mailing list to keep in touch with others working on  
> msysgit
> or 4msysgit, and do use the mob branch (you can bug the project  
> members
> listed on the homepage to cherry-pick, sign off and push if need be).
>

ok. I'll be available for one more week and will then be offline
for three weeks.

	Steffen

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

[Steffen Prohaska]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]


On Aug 8, 2007, at 9:37 PM, Steffen Prohaska wrote:

> I have a real Windows running in a Virtual Machine and I consider
> switching to it for a while, to see if things run smoothly. Here is
> what I plan to do: I will set cygwin to textmode (!), although I know
> better. But this is what most of the people I work with have. I'll
> uninstall cygwin's git and install msysgit instead. I'll try to do
> all the integration work, that is import from cvs on Linux, pull to
> Windows and do coding and merges on Windows. I'll push back to Linux
> and Mac for testing.

Here we go... I tried GitMe-3.exe.

I have two 'crashes' during installation. I attached snapshots
of the requesters. I don't know how to copy text from the
installer. Therefore I attached snapshots.

As mentioned before, I run in a virtual machine, Parallels to be exact.
I use my Windows installation rarely but I did not have any problems
with Windows in Parallels before.

	Steffen


  
        

[-- Attachment #2.1: requester1.png --]
[-- Type: application/applefile, Size: 74 bytes --]

[-- Attachment #2.2: requester1.png --]
[-- Type: image/png, Size: 8529 bytes --]

[-- Attachment #3.1: output2.png --]
[-- Type: application/applefile, Size: 71 bytes --]

[-- Attachment #3.2: output2.png --]
[-- Type: image/png, Size: 18058 bytes --]

[-- Attachment #4.1: requester2.png --]
[-- Type: application/applefile, Size: 74 bytes --]

[-- Attachment #4.2: requester2.png --]
[-- Type: image/png, Size: 8513 bytes --]

[-- Attachment #5: Type: text/plain, Size: 1 bytes --]



[-- Attachment #6.1: result.png --]
[-- Type: application/applefile, Size: 70 bytes --]

[-- Attachment #6.2: result.png --]
[-- Type: image/png, Size: 10023 bytes --]

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

[Steffen Prohaska]

On Aug 8, 2007, at 10:13 PM, Steffen Prohaska wrote:

> I have two 'crashes' during installation. I attached snapshots
> of the requesters. I don't know how to copy text from the
> installer. Therefore I attached snapshots.

Hmm... how do I get started? I naively chose cygwin as my
shell. I set

export PATH=$PATH:/cygdrive/c/msysgit/bin

then I tried

$ git clone git://git.kernel.org/pub/scm/git/git.git
c:/msysgit/bin/git-clone: line 214: git-init: command not found

Maybe it's related to the errors during installation?

How can I build and install git manually, based on the result
of GitMe-3's basic setup?

	Steffen

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

[Johannes Schindelin]

Hi,

On Wed, 8 Aug 2007, Steffen Prohaska wrote:

> On Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:
> 
> > So go for it, everybody, or alternatively do not even bother to whine.
> 
> I don't care about these things. I typically start the Explorer by 
> typing explorer into the 'Run ...' box of the start meny. So don't 
> expect anything from me that makes git more beautiful.

That's nice to hear.  Finally somebody honest.  I'll return the favour: I 
have no time to work on the bugs you sent in a reply.

Ciao,
Dscho

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

[Mark Levedahl]

Steffen Prohaska wrote:
>
Let me guess, you have Cygwin on the path along with Msys, and had it 
that way when you downloaded the package and it tried to build. Hmmm. 
Maybe Cygwin executables conflict with Msys executables. Nah. Couldn't 
be. Must be a bug.

Mark

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

[Steffen Prohaska]

On Aug 9, 2007, at 1:07 AM, Mark Levedahl wrote:

> Steffen Prohaska wrote:
>>
> Let me guess, you have Cygwin on the path along with Msys, and had  
> it that way when you downloaded the package and it tried to build.

I don't think so. At least I did not actively do something to
have Cygwin in my path.

	Steffen

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

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

>> I have two 'crashes' during installation. I attached snapshots of
>> the requesters. I don't know how to copy text from the installer.
>> Therefore I attached snapshots.
> 
> Hmm... how do I get started? I naively chose cygwin as my shell. I
> set
> 
> export PATH=$PATH:/cygdrive/c/msysgit/bin
> 
> then I tried
> 
> $ git clone git://git.kernel.org/pub/scm/git/git.git 
> c:/msysgit/bin/git-clone: line 214: git-init: command not found
> 
> Maybe it's related to the errors during installation?
> 
> How can I build and install git manually, based on the result of
> GitMe-3's basic setup?

Ok, first, which system is this? Windows 2000/XP/Vista?
(The Gitme installer doesn't work on old ones for now)

Try running gitme from a terminal. Download gitme-3.exe into C:\temp, 
open a native terminal (Start - Run - Type "cmd" <enter>); then in the 
terminal, type:
     C:\temp> set PATH=%WINDIR%\system32;%WINDIR%
     C:\temp> gitme-3

Does it work then? If so, the problem is likely to be that you have 
Cygwin in the system path, which is not advisable/compatible with MSys.

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

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

[Steffen Prohaska]

On Aug 8, 2007, at 11:30 PM, Johannes Schindelin wrote:

> Hi,
>
> On Wed, 8 Aug 2007, Steffen Prohaska wrote:
>
>> On Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:
>>
>>> So go for it, everybody, or alternatively do not even bother to  
>>> whine.
>>
>> I don't care about these things. I typically start the Explorer by
>> typing explorer into the 'Run ...' box of the start meny. So don't
>> expect anything from me that makes git more beautiful.
>
> That's nice to hear.  Finally somebody honest.  I'll return the  
> favour: I
> have no time to work on the bugs you sent in a reply.

That's fine. I don't expect anything, except for being honest about
the level of Windows support that is currently available. In retrospect,
I relied on the claim that git works in Cygwin without problems (not
made by you but on the mailing list in general). This claim turns out
to be wrong for me, because it highly depends on the details of how you
configure your Cygwin, which makes it impossible to run git in Cygwin
that is configured according to the 'wrong' policy.

Any hint how I can start debugging? I saw mingw for the
first time in my life, yesterday. I only worked with cygwin and various
Visual Studio versions, before.

[ btw, my point was that I'm mostly interested in getting the basic
stuff going first. That is git with the same functionality that
I have on Linux and Mac. The next would be a good integration with
useful tools on Windows, for example git-mergetool should launch
Windows three-way merge tools. The thing I'm least interested is
a beautiful installer, which clutters my Desktop with icons, which
I never use and need to cleanup later anyway.

Bottom line: if you have points on your list that better fit the
described priorities, there would be a good chance that I can look
into one or two of them, for example

Is anything needed to get mingw changes merged to the official repo?
Is anything needed to get changes from the official repo to mingw?

My goal would be to type 'make windist' in the official repo and
get a very basic installer (maybe just a zip archive) that contains
everything needed to run git on Windows. Unpacking this self-contained
installer on a freshly installed Windows should get you going. There
should be no need to install Cygwin or something else.

Is this realistic?
What is needed to get there?
What would be an estimated timeframe to achieve this goal?

Will all this run on Windows XP 64 bit and Windows Vista 64 bit?

After I'm convinced that the level of support for Windows is
sufficient, I will recommend using it, which means that approximately
30 developers will start using git in the way I describe to them.
This will generate a lot of real-world testing. But it should not
generate too many critical issues. People will blame me for
recommending them the tool. ]


Back to debugging...

I tried the following (is this the right way to go?)

- double click on c:\msysgit\msys.bat to start a shell.
- cd git
- make
compiles with some warnings ..., and crashed with a popup...
The popup says (translated to english):
"NTVDM-CPU detected an invalid instruction.
CS:0000 IP:0077 OP: f0 37 05 0c 02 click to close the application."

the last lines I see in the shell are

LINK test-match-trees.exe
SUBDIR git-gui
INDEX lib/

I clicked and the compilation stops. My shell remains alive.
So, I started to run tests.

t0000-basic fails on creation of symlinks. Apparently mingw
doesn't support symlinks to files that do not exist. I reports
'ln: creating symbolic link 'path0sym' to 'hello path0' fails'.

I tried with 'export no_symlinks=1' (is this the right thing
to do? Who should set no_symlinks=1? Should it be set by the
makefile or in some global architecture configuration?).

Now t0000-basic runs except for some noise created by failing
ln, which is not detected as a failure by the test script.

so I ran all tests and they look good. Only t7004
reported 'gpg: error loading iconv.dll'.

I tried 'make install' which yields another crash popup.
Then I tried 'make -k install'

Wow... this crashed my virtual machine. Maybe Parallels should
add msysgit to their test cases. If I read their automatically
generated bugreport correctly it's again related to an invalid
instruction. Maybe mingw uses some op codes it shouldn't?

Hmm... I planned to upgrade to the newest release of Parallels
anyway. Hopefully it's more stable in this regards.

I set NO_TCLTK=1 in the Makefile to skip git-gui during installation.
The installation finished without reporting any problem. Maybe
I have a working git now ...

	Steffen

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

[Steffen Prohaska]

On Aug 9, 2007, at 8:01 AM, Marius Storm-Olsen wrote:

>>> I have two 'crashes' during installation. I attached snapshots of
>>> the requesters. I don't know how to copy text from the installer.
>>> Therefore I attached snapshots.
>> Hmm... how do I get started? I naively chose cygwin as my shell. I
>> set
>> export PATH=$PATH:/cygdrive/c/msysgit/bin
>> then I tried
>> $ git clone git://git.kernel.org/pub/scm/git/git.git c:/msysgit/ 
>> bin/git-clone: line 214: git-init: command not found
>> Maybe it's related to the errors during installation?
>> How can I build and install git manually, based on the result of
>> GitMe-3's basic setup?
>
> Ok, first, which system is this? Windows 2000/XP/Vista?
> (The Gitme installer doesn't work on old ones for now)

XP 32bit.

> Try running gitme from a terminal. Download gitme-3.exe into C: 
> \temp, open a native terminal (Start - Run - Type "cmd" <enter>);  
> then in the terminal, type:
>     C:\temp> set PATH=%WINDIR%\system32;%WINDIR%
>     C:\temp> gitme-3

> Does it work then? If so, the problem is likely to be that you have  
> Cygwin in the system path, which is not advisable/compatible with  
> MSys.

I had cygwin at the tail of my PATH. After removing it the
installation went through flawlessly.

A check in the installer would be a good idea.

Would you recommend running git only from the mingw shell prompt,
or can I start it also from a Cygwin shell prompt?

Thanks a lot,

	Steffen

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

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

Steffen Prohaska said the following on 09.08.2007 08:38:
> On Aug 9, 2007, at 8:01 AM, Marius Storm-Olsen wrote:
>> Does it work then? If so, the problem is likely to be that you
>> have Cygwin in the system path, which is not advisable/compatible
>> with MSys.
> 
> I had cygwin at the tail of my PATH. After removing it the 
> installation went through flawlessly.
> 
> A check in the installer would be a good idea.
> 
> Would you recommend running git only from the mingw shell prompt, 
> or can I start it also from a Cygwin shell prompt?

Well, some say that you can, but I'm not sure (especially since you're 
using Cygwin in Windows EOL mode, which is opposite of MSys).
The way I use it is either from the MSys shell, or directly from CMD 
shell. (If you have PATH=c:\msysgit\bin;C:\msysgit\mingw\bin;%PATH% it 
works quite well like that.)

Actually, I use CMD most of the time..

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

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

[Johannes Schindelin]

Hi,

On Thu, 9 Aug 2007, Marius Storm-Olsen wrote:

> Try running gitme from a terminal.

And there I thought that you download GitMe-3.exe, and then double click 
on it...

Ciao,
Dscho

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

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Johannes Schindelin said the following on 09.08.2007 10:50:
> On Thu, 9 Aug 2007, Marius Storm-Olsen wrote:
>> Try running gitme from a terminal.
> And there I thought that you download GitMe-3.exe, and then double
> click on it...

Heh, yeah, normally that's indeed what you do. However, in this case I 
asked him to start it from the terminal to make sure that it wasn't 
affected by anything suspicious in his system PATH.

Clearly having Cygwin in his path messed things up.

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

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

[Steffen Prohaska]

On Aug 9, 2007, at 11:00 AM, Marius Storm-Olsen wrote:

> Johannes Schindelin said the following on 09.08.2007 10:50:
>> On Thu, 9 Aug 2007, Marius Storm-Olsen wrote:
>>> Try running gitme from a terminal.
>> And there I thought that you download GitMe-3.exe, and then double
>> click on it...
>
> Heh, yeah, normally that's indeed what you do. However, in this  
> case I asked him to start it from the terminal to make sure that it  
> wasn't affected by anything suspicious in his system PATH.
>
> Clearly having Cygwin in his path messed things up.

I think checking for a proper setup in the installer would
be a good idea, like checking if 'cygpath' runs and if so,
die with the request to cleanup the system PATH first.

The problem was not too hard to solve, but the first
impression was not optimal.

Where would I have to look to add something like this?

	Steffen

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

[Torgil Svensson]

On 8/9/07, Steffen Prohaska <prohaska@zib.de> wrote:

> The next would be a good integration with
> useful tools on Windows, for example git-mergetool should launch
> Windows three-way merge tools.

Do you mean tools included in Windows or tools using the Windows API?


> My goal would be to type 'make windist' in the official repo and
> get a very basic installer (maybe just a zip archive) that contains
> everything needed to run git on Windows. Unpacking this self-contained
> installer on a freshly installed Windows should get you going. There
> should be no need to install Cygwin or something else.
>
> Is this realistic?
> What is needed to get there?
> What would be an estimated timeframe to achieve this goal?
>
> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?

How fast can you type?

Why does it have to be the _official_ repo? Git have submodule
support, so you could do a repo called
"my_excellent_git_environment_for_windows.git" and have the official
repo as submodule (msysgit is done this way).

You could even start with cloning the TortoiseSVN repo using git. Or
maybe even better, since KDE4 will compile on Windows [take on wood],
do it as a kioslave (or whatever mechanism) to have an environment
that works in both Windows and Linux and most OtherOs:es. Aiming for
environments that works on several OSes is a good thing for future
migrations.

//Torgil

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

[Steffen Prohaska]

On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:

> On 8/9/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
>> The next would be a good integration with
>> useful tools on Windows, for example git-mergetool should launch
>> Windows three-way merge tools.
>
> Do you mean tools included in Windows or tools using the Windows API?

I think both. I'm currently conducting a survey what the Windows
users I'm working with are using. Up to now I have no idea what these
tools do. Note, I'm not working on Windows. But I would like to see
git starting the tools that users prefer to use.

Git would just feel more like a useful Windows tool if it interacted
with other useful Windows tools.

Here is what I have on my list (not yet prioritized):

- WinMerge (http://winmerge.org/)

- Visual Comparer (http://www.nikeware.com/vc-features.htm)

- Araxis Merge, http://www.araxis.com/merge/ (expensive!)

- Beyond Compare, http://www.scootersoftware.com/file-comparison.php  
(will support 3-way  with upcoming version 3; reasonable price)

- KDiff3, http://kdiff3.sourceforge.net/ (comes with Windows- 
installer from SF)

- ECMerge, http://www.elliecomputing.com/Products/merge_overview.asp  
(OSS developer can get a "Pro" license for free upon request)

A complete list at
http://en.wikipedia.org/wiki/Comparison_of_file_comparison_tools


>
>> My goal would be to type 'make windist' in the official repo and
>> get a very basic installer (maybe just a zip archive) that contains
>> everything needed to run git on Windows. Unpacking this self- 
>> contained
>> installer on a freshly installed Windows should get you going. There
>> should be no need to install Cygwin or something else.
>>
>> Is this realistic?
>> What is needed to get there?
>> What would be an estimated timeframe to achieve this goal?
>>
>> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
>
> How fast can you type?

I don't see your point. The question is if git runs flawlessly
on 64 bit systems, which we use for development. I have no experience
with mingw. Maybe there are some issues with 64 bit Windows, maybe
not. But its a reasonable question?


> Why does it have to be the _official_ repo? Git have submodule
> support, so you could do a repo called
> "my_excellent_git_environment_for_windows.git" and have the official
> repo as submodule (msysgit is done this way).

The official repo would indicate a real commitment to me that
Windows support if officially maintained.

I agree that there may be more tools group around core git. But
core git itself should be the master from the official repo.
This seems to be a reasonable goal to me. At least that is what
we do. The head must compile on all supported platforms
out-of-the-box.


> You could even start with cloning the TortoiseSVN repo using git. Or
> maybe even better, since KDE4 will compile on Windows [take on wood],
> do it as a kioslave (or whatever mechanism) to have an environment
> that works in both Windows and Linux and most OtherOs:es. Aiming for
> environments that works on several OSes is a good thing for future
> migrations.

I work for years now on cross platform code. I never needed a whole
environment. I need Qt and the native development environment, like
Visual Studio, gcc, Xcode. I don't need KDE on Windows, I don't need
KDE on Mac. Everything's there already.

	Steffen

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

[Johannes Schindelin]

Hi,

On Fri, 10 Aug 2007, Steffen Prohaska wrote:

> On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:
> 
> > On 8/9/07, Steffen Prohaska <prohaska@zib.de> wrote:
> > 
> > > Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
> > 
> > How fast can you type?
> 
> I don't see your point. The question is if git runs flawlessly
> on 64 bit systems, which we use for development. I have no experience
> with mingw. Maybe there are some issues with 64 bit Windows, maybe
> not. But its a reasonable question?

It would be, if

- more people had 64-bit platforms to run on, and
- more people had Windows 64-bit.

Both cost money, so I suggest just trying it for yourself if you are one 
of the few lucky ones being actually _able_ to test.

And no, I will not buy a Windows 64-bit just to test it for you.

> > Why does it have to be the _official_ repo? Git have submodule
> > support, so you could do a repo called
> > "my_excellent_git_environment_for_windows.git" and have the official
> > repo as submodule (msysgit is done this way).
> 
> The official repo would indicate a real commitment to me that
> Windows support if officially maintained.

I cannot speak for others, of course, but this is a freeloader mentality I 
do not want to support.

If you want first class Windows support, you'll have to pay for that, 
methinks.  And seeing all those less-than-even-lousy SCMs getting major 
financial contributions to support their mediocrity, I do not see a reason 
to get small amounts from private people, but rather substantial 
money-flow from big companies.

Git is an excellent tool.  If people want it badly enough, they should do 
something for it.

> I agree that there may be more tools group around core git. But
> core git itself should be the master from the official repo.
> This seems to be a reasonable goal to me. At least that is what
> we do. The head must compile on all supported platforms
> out-of-the-box.

Guess why mingw.git is called a "fork"?  It is _not good enough_ yet to be 
included.  Not necessarily function-wise, but definitely code-wise.  We 
have quite strict coding rules, being an Open Source project where 
everybody can see your mess, should there be one.

It has _never_ been the plan to maintain mingw.git independently for 
eternity.  But the progress has been slow, and the _only_ reason that 
there was any progress _at all_ was that Hannes stepped up, and did some 
actual work instead of talking.

So yes, mingw.git's target destination is git.git.

Ciao,
Dscho

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

[Steffen Prohaska]

On Aug 10, 2007, at 12:30 PM, Johannes Schindelin wrote:

> Hi,
>
> On Fri, 10 Aug 2007, Steffen Prohaska wrote:
>
>> On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:
>>
>>> On 8/9/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>>
>>>> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
>>>
>>> How fast can you type?
>>
>> I don't see your point. The question is if git runs flawlessly
>> on 64 bit systems, which we use for development. I have no experience
>> with mingw. Maybe there are some issues with 64 bit Windows, maybe
>> not. But its a reasonable question?
>
> It would be, if
>
> - more people had 64-bit platforms to run on, and
> - more people had Windows 64-bit.
>
> Both cost money, so I suggest just trying it for yourself if you  
> are one
> of the few lucky ones being actually _able_ to test.
>
> And no, I will not buy a Windows 64-bit just to test it for you.

I'll try. I only asked if there is any experience on this. I didn't
ask you to test it for me.


>>> Why does it have to be the _official_ repo? Git have submodule
>>> support, so you could do a repo called
>>> "my_excellent_git_environment_for_windows.git" and have the official
>>> repo as submodule (msysgit is done this way).
>>
>> The official repo would indicate a real commitment to me that
>> Windows support if officially maintained.
>
> I cannot speak for others, of course, but this is a freeloader  
> mentality I
> do not want to support.
>
> If you want first class Windows support, you'll have to pay for that,
> methinks.  And seeing all those less-than-even-lousy SCMs getting  
> major
> financial contributions to support their mediocrity, I do not see a  
> reason
> to get small amounts from private people, but rather substantial
> money-flow from big companies.
>
> Git is an excellent tool.  If people want it badly enough, they  
> should do
> something for it.

You may have noticed that I'm willing to put some time into
it. I can't offer money. Time should be fine, too as you
state on msysgit's homepage

"Testing and reporting bugs is really already a big help.
Of course, it is even better if you get involved, for example
by hacking on mingw.git."

That is what I'm doing. You get bug reports and you get
patches. I don't understand your point about freeloader
mentality. In the long run it's just easier to keep functionality
in sync if it is maintained in a single repo, and this is what
you're basically also saying below.


>> I agree that there may be more tools group around core git. But
>> core git itself should be the master from the official repo.
>> This seems to be a reasonable goal to me. At least that is what
>> we do. The head must compile on all supported platforms
>> out-of-the-box.
>
> Guess why mingw.git is called a "fork"?  It is _not good enough_  
> yet to be
> included.  Not necessarily function-wise, but definitely code- 
> wise.  We
> have quite strict coding rules, being an Open Source project where
> everybody can see your mess, should there be one.

Well and here, again, is my point of one single repo that officially
supports Windows. If the official support is part of the 'quite
strict coding' rules then I'm more convinced that Windows is
supported with appropriate quality. This is the point I want to make.
It has nothing to do with freeloader mentality.


> It has _never_ been the plan to maintain mingw.git independently for
> eternity.  But the progress has been slow, and the _only_ reason that
> there was any progress _at all_ was that Hannes stepped up, and did  
> some
> actual work instead of talking.
>
> So yes, mingw.git's target destination is git.git.

Good to hear. Again, I prefer to put work into pushing the merge
with git.git forward, than putting work into any fancy gui stuff,
as you proposed recently.

So if there's a list of todos that hinder a merge back to git.git,
I'd happy to learn about it.

	Steffen

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

[Torgil Svensson]

On 8/10/07, Steffen Prohaska <prohaska@zib.de> wrote:

>  [..list of tools and links]

Thank you for the information!  i'll check those up.

> >> My goal would be to type 'make windist' in the official repo and
> >> get a very basic installer (maybe just a zip archive) that contains
> >> everything needed to run git on Windows. Unpacking this self-
> >> contained
> >> installer on a freshly installed Windows should get you going. There
> >> should be no need to install Cygwin or something else.
> >>
> >> Is this realistic?
> >> What is needed to get there?
> >> What would be an estimated timeframe to achieve this goal?
> >>
> >> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
> >
> > How fast can you type?
>
> I don't see your point. The question is if git runs flawlessly
> on 64 bit systems, which we use for development. I have no experience
> with mingw. Maybe there are some issues with 64 bit Windows, maybe
> not. But its a reasonable question?
>
> > Why does it have to be the _official_ repo? Git have submodule
> > support, so you could do a repo called
> > "my_excellent_git_environment_for_windows.git" and have the official
> > repo as submodule (msysgit is done this way).
>
> The official repo would indicate a real commitment to me that
> Windows support if officially maintained.

I agree it's reasonable questions. My point is that to get something,
you have to be active (and you're a prime example of that I think).

Quoted from http://git.or.cz/ : "Traditionally, the low-level part of
Git is called plumbing and the interfaces and frontends are called
porcelains. Git itself comes with a default porcelain bundled and that
is actually what you will normally mean when you say you use Git."


What do you include in the "make windist" installer and the "Windows
support" ?  Are you talking porcelain or plumbing?

>> Aiming for
>> environments that works on several OSes is a good thing for future
>> migrations.
> I work for years now on cross platform code. I never needed a whole
> environment. I need Qt and the native development environment, like
> Visual Studio, gcc, Xcode. I don't need KDE on Windows, I don't need
> KDE on Mac. Everything's there already.

Good thing you're flexible and have a broad experience. Not everyone
out there has that and it can be tricky to try to lure those people
away from 10yrs habits.

//Torgil

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

[Steffen Prohaska]

On Aug 11, 2007, at 12:31 AM, Torgil Svensson wrote:

> On 8/10/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
>>  [..list of tools and links]
>
> Thank you for the information!  i'll check those up.


I hope to have an improved list on monday, sorted by priority of
the developers I'm working with.

I thought I do some coding, to find out a bit more about the
stability of msysgit. So I started and added support for kdiff3
on Windows (see patches in separate mail).

I'm impressed. Pretty much everything I tried today worked for
me. After I got git gui running, and learned how to avoid pitfalls
of git submodule, development went smoothly. I pushed and pulled a
bit from linux and mac and did some coding. Thanks for the vim
setup!

I think you (and more people I don't yet know) did a great job
with msysgit. I'd recommend it over cygwin's git, which caused
some trouble for me.

Thanks!

>>>> My goal would be to type 'make windist' in the official repo and
>>>> get a very basic installer (maybe just a zip archive) that contains
>>>> everything needed to run git on Windows. Unpacking this self-
>>>> contained
>>>> installer on a freshly installed Windows should get you going.  
>>>> There
>>>> should be no need to install Cygwin or something else.
>>>>
>>>> Is this realistic?
>>>> What is needed to get there?
>>>> What would be an estimated timeframe to achieve this goal?
>>>>
>>>> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
>>>
>>> How fast can you type?
>>
>> I don't see your point. The question is if git runs flawlessly
>> on 64 bit systems, which we use for development. I have no experience
>> with mingw. Maybe there are some issues with 64 bit Windows, maybe
>> not. But its a reasonable question?
>>
>>> Why does it have to be the _official_ repo? Git have submodule
>>> support, so you could do a repo called
>>> "my_excellent_git_environment_for_windows.git" and have the official
>>> repo as submodule (msysgit is done this way).
>>
>> The official repo would indicate a real commitment to me that
>> Windows support if officially maintained.
>
> I agree it's reasonable questions. My point is that to get something,
> you have to be active (and you're a prime example of that I think).
>
> Quoted from http://git.or.cz/ : "Traditionally, the low-level part of
> Git is called plumbing and the interfaces and frontends are called
> porcelains. Git itself comes with a default porcelain bundled and that
> is actually what you will normally mean when you say you use Git."
>
>
> What do you include in the "make windist" installer and the "Windows
> support" ?  Are you talking porcelain or plumbing?

Hard to say. I believe now, from what I learned today, that the msysgit
approach is quite reasonable: Grouping all needed unix tools around a
submodule containing git. But the submodule should be git.git. I think
this is what I'd expect. I like the idea of bringing everything needed
along, and keeping it separate from the rest of the system. This avoids
conflicts with, for example, cygwin.

I don't think I would expect much more for a basic setup. All tests
should run, maybe some msysgit tests would be needed to test the  
pitfalls
we'll discover; maybe not. I'll test XP 64 bit and Vista 64 bit  
beginning
of next week. Getting started hacking msysgit could be a bit easier.
I didn't like the submodule problems I ran into and I still didn't find
out how to push to the git mob branch.

For me a next step would be do some polishing. For example tune
git to integrate with other Windows tools, like what I proposed for
git-mergetool. I really started to love git when it launched a
graphical mergetool automatically for me. After that point I never
edited merge markers again. Things I needed too much time before are
now running so smoothly. I think such a tight integration is really
useful to convince people. I'd also expect default choices to be
reasonable. I'm not yet 100% sure, but my feeling it that core.autocrlf
should be set to true by default on Windows, globally. A bit more
of msysgit specific documentation would also be good. Maybe we should
add a platform specific section to the user-manual. How could help
in msysgit be handled? By a Windows help document?

I could also think of a fail safe update, that allows to upgrade an
existing msysgit to a specific tag (maybe after stashing the current
installation and reverting in case of problems).

Maybe git gui could be integrated with the Windows Explorer and be
launched on a directory. Maybe this is one of your evil plans. But
this is already more than I need.

Back to the basic stuff.
What do you think is needed to merge changes back to git.git?
I counted approximately 20k diff lines (incl. context) between msysgit's
git master and git.git's master. At a first glance much of them seem to
be compatibility stuff.

	Steffen

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

[Johannes Schindelin]

Hi,

On Sat, 11 Aug 2007, Steffen Prohaska wrote:

> I'm impressed. Pretty much everything I tried today worked for me. After 
> I got git gui running, and learned how to avoid pitfalls of git 
> submodule, development went smoothly.

Thanks!

> I could also think of a fail safe update, that allows to upgrade an 
> existing msysgit to a specific tag (maybe after stashing the current 
> installation and reverting in case of problems).

It's pretty early to think about stable releases, let alone upgrades ;-)

> Maybe git gui could be integrated with the Windows Explorer and be 
> launched on a directory. Maybe this is one of your evil plans. But this 
> is already more than I need.

That is already in the works.  An alpha version is already working.

> What do you think is needed to merge changes back to git.git? I counted 
> approximately 20k diff lines (incl. context) between msysgit's git 
> master and git.git's master. At a first glance much of them seem to be 
> compatibility stuff.

It is _all_ compatibility stuff.

Basically, it all boils down to grabbing a specific part of the diff 
related to a certain concept (such as NO_IPV6), and whip the patch 
(series) into shape.

Submit it to git.git.  Work on it until it is part of the official 
distribution.

Continue with the next part of the diff.

Ciao,
Dscho

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

[Torgil Svensson]

On 8/11/07, Steffen Prohaska <prohaska@zib.de> wrote:

> >>  [..list of tools and links]
> >
> > Thank you for the information!  i'll check those up.
>
>
> I hope to have an improved list on monday, sorted by priority of
> the developers I'm working with.
>
> I thought I do some coding, to find out a bit more about the
> stability of msysgit. So I started and added support for kdiff3
> on Windows (see patches in separate mail).

neat.The hardest part for me was to find out that I didn't have to
configure anything or add a command line option to get kdiff3 running.
(I cheated looking in the source, I think we should add #ifdef
__MINGW32__ / #endif around the registry reading part.

Good job!




> I'm impressed. Pretty much everything I tried today worked for
> me. After I got git gui running, and learned how to avoid pitfalls
> of git submodule, development went smoothly. I pushed and pulled a
> bit from linux and mac and did some coding. Thanks for the vim
> setup!
>
> I think you (and more people I don't yet know) did a great job
> with msysgit. I'd recommend it over cygwin's git, which caused
> some trouble for me.

Thanks. I'm as fresh as you in msysgit development but it is quite
straightforward. I've fiddled around with cygwin/msys before but now I
think we're on to something useful.


> > What do you include in the "make windist" installer and the "Windows
> > support" ?  Are you talking porcelain or plumbing?
>
> Hard to say. I believe now, from what I learned today, that the msysgit
> approach is quite reasonable: Grouping all needed unix tools around a
> submodule containing git. But the submodule should be git.git. I think
> this is what I'd expect. I like the idea of bringing everything needed
> along, and keeping it separate from the rest of the system. This avoids
> conflicts with, for example, cygwin.


> I don't think I would expect much more for a basic setup. All tests
> should run, maybe some msysgit tests would be needed to test the
> pitfalls

I'm lacking several things. Many usability-glitches, some bugs, easy
access to documentation. Also we want to integrate the mingw git parts
into git.git so people can follow the official repo. etc..

> I didn't like the submodule problems I ran into and I still didn't find
> out how to push to the git mob branch.

This is weird. I haven't had such problems with this (dirty submodule
in working dir), but that probably is because the supermodule doesn't
depend on files in the submodule [submodule "make install" copies
files to the supermodule]. Otherwise we should be more dependent on a
clean submodule state.  I would though expect a "git reset --hard" to
fix up the submodule for me.


> [ many proposals for future work with msysgit]

Yeah. there's plenty of stuff to do. You could add this stuff to the
issue tracker Dimitry has initiated.

//Torgil

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

[Steffen Prohaska]

On Aug 15, 2007, at 2:04 AM, Torgil Svensson wrote:

> On 8/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
>>>>  [..list of tools and links]
>>>
>>> Thank you for the information!  i'll check those up.
>>
>>
>> I hope to have an improved list on monday, sorted by priority of
>> the developers I'm working with.
>>
>> I thought I do some coding, to find out a bit more about the
>> stability of msysgit. So I started and added support for kdiff3
>> on Windows (see patches in separate mail).
>
> neat.The hardest part for me was to find out that I didn't have to
> configure anything or add a command line option to get kdiff3 running.
> (I cheated looking in the source, I think we should add #ifdef
> __MINGW32__ / #endif around the registry reading part.

What does __MINGW32__ mean for shell code? The registry reading
should just be ignored if registry access 'reg.exe' is not available.

However, the code was not yet robust. I pushed the patch below to
4msysgit.git's mob.

	Steffen


commit 816f61fecd9e90879afcbad9234f19bf6d982b76
Author: Johannes Schmidt-Ehrenberg <schmidt-ehrenberg@zib.de>
Date:   Mon Aug 13 19:00:39 2007 +0200

     mergetool: fixed parsing of registry entry for kdiff3

     The old code failed on Windows Vista. The output of
     reg.exe or something else may be a bit different.
     This patch improves the parsing code to be more robust.

     Signed-off-by: Steffen Prohaska <prohaska@zib.de>

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

[David Kastrup]

Steffen Prohaska <prohaska@zib.de> writes:

> Author: Johannes Schmidt-Ehrenberg <schmidt-ehrenberg@zib.de>
> Date:   Mon Aug 13 19:00:39 2007 +0200
>
>     mergetool: fixed parsing of registry entry for kdiff3
>
>     The old code failed on Windows Vista. The output of
>     reg.exe or something else may be a bit different.
>     This patch improves the parsing code to be more robust.

I seem to remember that you can't rely on reg.exe being available on
Windows.  The Microsoft support pages talk about using regedit.exe
instead (which is quite more cumbersome).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Steffen Prohaska]

On Aug 15, 2007, at 7:30 AM, David Kastrup wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Author: Johannes Schmidt-Ehrenberg <schmidt-ehrenberg@zib.de>
>> Date:   Mon Aug 13 19:00:39 2007 +0200
>>
>>     mergetool: fixed parsing of registry entry for kdiff3
>>
>>     The old code failed on Windows Vista. The output of
>>     reg.exe or something else may be a bit different.
>>     This patch improves the parsing code to be more robust.
>
> I seem to remember that you can't rely on reg.exe being available on
> Windows.  The Microsoft support pages talk about using regedit.exe
> instead (which is quite more cumbersome).

I successfully ran it on at least Windows XP and Vista. On Vista,
it was present on a quite fresh system (Visual Studio not yet
installed). So I'm quite confident that it's likely to be there.

Do you have a reference? I searched msdn and was not able to
immediately find the recommendation you're referring to.

	Steffen

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

[David Kastrup]

Steffen Prohaska <prohaska@zib.de> writes:

> On Aug 15, 2007, at 7:30 AM, David Kastrup wrote:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>> Author: Johannes Schmidt-Ehrenberg <schmidt-ehrenberg@zib.de>
>>> Date:   Mon Aug 13 19:00:39 2007 +0200
>>>
>>>     mergetool: fixed parsing of registry entry for kdiff3
>>>
>>>     The old code failed on Windows Vista. The output of
>>>     reg.exe or something else may be a bit different.
>>>     This patch improves the parsing code to be more robust.
>>
>> I seem to remember that you can't rely on reg.exe being available on
>> Windows.  The Microsoft support pages talk about using regedit.exe
>> instead (which is quite more cumbersome).
>
> I successfully ran it on at least Windows XP and Vista. On Vista,
> it was present on a quite fresh system (Visual Studio not yet
> installed). So I'm quite confident that it's likely to be there.
>
> Do you have a reference? I searched msdn and was not able to
> immediately find the recommendation you're referring to.

<http://www.microsoft.com/technet/prodtechnol/Windows2000serv/support/FAQW2KCP.mspx>

    Q.	What other tools are available for using the registry in batch?
    A.	

    If you install the Support Tools from the Windows 2000 CD-ROM, you
    can use REG.EXE to Add, Delete, Copy, Compare, Export, Import,
    Load a Hive, Query, Save, Restore, and Unload a Hive. To install
    the Support Tools:

    1.


    Insert the Windows 2000 CD-ROM into your CD-ROM drive.

    2.


    Click Browse this CD, and then open the Support\Tools folder.

    3.


    Double-click Setup.exe, and follow the on-screen instructions.


That does not sound like one could rely on its presence out of the
box, at least on Windows 2000.

-- 
David Kastrup

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

[Shawn O. Pearce]

David Kastrup <dak@gnu.org> wrote:
>     Load a Hive, Query, Save, Restore, and Unload a Hive. To install
>     the Support Tools:
> 
>     1.
> 
> 
>     Insert the Windows 2000 CD-ROM into your CD-ROM drive.

Indeed, that step right there will stop many users cold in their
tracks.

Who the hell has their Windows 2000 CD-ROM handy?  Or wants to open a
CD-ROM drive?  Or wants to wait for a 40x CD-ROM to spin up and copy
data?  Who even still has a CD-ROM drive connected to a computer?
(I usually don't have any optical media drive attached...)

Where's the damn URL to download setup.exe?  Where's the webpage
with the Internet Explorer buffer overflow exploit to automatically
install the software for the user?  Why doesn't it create a thousand
icons on the desktop, obscuring the user's picture of their kitty?

;-)

-- 
Shawn.

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

[Mark Levedahl]

On 8/15/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> David Kastrup <dak@gnu.org> wrote:
> >     Load a Hive, Query, Save, Restore, and Unload a Hive. To install
> >     the Support Tools:
> >
> >     1.
> >
> >
> >     Insert the Windows 2000 CD-ROM into your CD-ROM drive.
>
> Indeed, that step right there will stop many users cold in their
> tracks.

maybe something like ...

case "$(uname -o) in

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

[Mark Levedahl]

On 8/15/07, Mark Levedahl <mlevedahl@gmail.com> wrote:
> On 8/15/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > David Kastrup <dak@gnu.org> wrote:
> > >     Load a Hive, Query, Save, Restore, and Unload a Hive. To install
> > >     the Support Tools:
> > >
> > >     1.
> > >
> > >
> > >     Insert the Windows 2000 CD-ROM into your CD-ROM drive.
> >
> > Indeed, that step right there will stop many users cold in their
> > tracks.
>
maybe something like ...

case "$(uname -s) in
   MSYS*)
       <your way>;;
   *)
       <the unix way>;;
esac

Mark

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

[Steffen Prohaska]

On Aug 15, 2007, at 2:48 PM, Mark Levedahl wrote:

> On 8/15/07, Mark Levedahl <mlevedahl@gmail.com> wrote:
>> On 8/15/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>>> David Kastrup <dak@gnu.org> wrote:
>>>>     Load a Hive, Query, Save, Restore, and Unload a Hive. To  
>>>> install
>>>>     the Support Tools:
>>>>
>>>>     1.
>>>>
>>>>
>>>>     Insert the Windows 2000 CD-ROM into your CD-ROM drive.
>>>
>>> Indeed, that step right there will stop many users cold in their
>>> tracks.
>>
> maybe something like ...
>
> case "$(uname -s) in
>    MSYS*)
>        <your way>;;
>    *)
>        <the unix way>;;
> esac

If reg.exe is not there kdiff3 will not be found. The code will
already be _ignored_. It's just not working.

It may make sense to use 'uname -s' to explicitly control that the
code is expected to work. This would allow to report errors if a
command is missing. However, cluttering all shell scripts with
uname's will likely become quite confusing.

If performance is a concern, we may execute uname -s only once
in git-sh-setup and assign its return to something like GIT_UNAME.
This may save us a few forks, which are to my knowledge quite
expensive on Windows.

	Steffen

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

[Mark Levedahl]

Steffen Prohaska wrote:
>
> If reg.exe is not there kdiff3 will not be found. The code will
> already be _ignored_. It's just not working.
I'm really thinking forward to when you try to reintegrate this into 
git.git: Platform specific code needs to be wrapped with a test that has 
a known result on all platforms.

Mark

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

[Steffen Prohaska]

On Aug 16, 2007, at 2:27 AM, Mark Levedahl wrote:

> Steffen Prohaska wrote:
>>
>> If reg.exe is not there kdiff3 will not be found. The code will
>> already be _ignored_. It's just not working.
> I'm really thinking forward to when you try to reintegrate this  
> into git.git: Platform specific code needs to be wrapped with a  
> test that has a known result on all platforms.

I thought about that, too.

The code works on _all_ platforms as follows:
- if 'REG' is available, its output is parsed for the diffcommand;
- if 'REG' is not available the code is ignored.

The only problem I see with this approach is that the code does not
test if 'REG' was present and returned an error for an unknown reason.
btw, in merge tool we would probably ignore such an error anyway.


What does 'platform specific' mean? Is MINGW the platform? If so,
how about Cygwin? Or is Windows the platform?

Windows will often be the right choice.

So how do we test for Windows?

On my machine uname returns the following in Cygwin and Mingw
- CYGWIN_NT-5.1
- MINGW32_NT-5.1


The patch I sent does not test for platforms, but assumes that 'REG'
will only be available on Windows. Errors will just be ignored, which
is is not perfect. This could be improved by testing first if 'REG' is
available and if so report errors returned by REG.

Assuming that 'REG' is only available on Windows and has a defined
meaning seems to be reasonable assumption to me. I don't see the need
to test which platform the script is running on. Testing if 'REG' is
available seems to be sufficient.

	Steffen

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

[Mark Levedahl]

> Assuming that 'REG' is only available on Windows and has a defined
> meaning seems to be reasonable assumption to me. I don't see the need
> to test which platform the script is running on. Testing if 'REG' is
> available seems to be sufficient.
>
>         Steffen
>

I don't think that REG is a a name reserved for use only on Windows
that could never exist on another box. Its meaning is undefined
outside of Windows. Undefined means unreliable and therefore, not
useful as a test to decide what to do on arbitrary platforms. Also, on
Cygwin you would use regtool and parse things differently anyway,
while Cygwin users tend to be educable enough that if they want to use
kdiff or whatever, they'll symlink it or otherwise put it on their
path.

Mark