{"thread":{"id":"9422","subject":"git on Cygwin: Not a valid object name HEAD","startedAt":"2007-08-07T09:02:13Z","lastAt":"2007-08-16T11:55:55Z","messageCount":60,"participants":["Sebastian Schuberth","Johannes Schindelin","Shawn O. Pearce","Brian Downing","Mark Levedahl","Steffen Prohaska","Linus Torvalds","Junio C Hamano","Marius Storm-Olsen","Torgil Svensson","David Kastrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50106","messageId":"f99cem$4a4$1@sea.gmane.org","threadId":"9422","inReplyTo":null,"subject":"git on Cygwin: Not a valid object name HEAD","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2007-08-07T09:02:13Z","receivedAt":"2007-08-07T09:02:13Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"Hi,\n\nI'm running git 1.5.2.2 under Cygwin on Windows XP. This is what I'm \n(reproducibly) getting if I try to clone QGit's repository:\n\nsschuber@xp-sschuber2 ~\n$ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git\nInitialized empty Git repository in /home/sschuber/qgit4/.git/\nremote: Generating pack...\nremote: Done counting 2295 objects.\nremote: Deltifying 2295 objects...\nremote: 100% (2295/2295) done\nIndexing 2295 objects...\nremote: Total 2295 (delta 1793), reused 1218 (delta 955)\n 100% (2295/2295) done\nResolving 1793 deltas...\n 100% (1793/1793) done\n: not a valid SHA1b870df7cde1e05ee76d1d15ea428f\nfatal: Not a valid object name HEAD\n\nsschuber@xp-sschuber2 ~\n$ git --version\ngit version 1.5.2.2\n\nI'm not sure whether the cause for this is the same as mentioned at\n\nhttp://article.gmane.org/gmane.comp.version-control.git/54825\n\nHowever, the most recent msysGit worked fine for me. Any clues whether \nthis is a repository problem, a Cygwin problem, or a git problem?\n\nThanks.\n\n-- \nSebastian Schuberth\n"},{"id":"50118","messageId":"Pine.LNX.4.64.0708071257350.14781@racer.site","threadId":"9422","inReplyTo":"f99cem$4a4$1@sea.gmane.org","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-07T11:58:17Z","receivedAt":"2007-08-07T11:58:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 7 Aug 2007, Sebastian Schuberth wrote:\n\n> 100% (2295/2295) done\n> Resolving 1793 deltas...\n> 100% (1793/1793) done\n> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f\n> fatal: Not a valid object name HEAD\n\nI suspect that there is no master branch on the remote side, but the \nremote's HEAD points there. Try \"git ls-remote \" to find out.\n\nCiao,\nDscho\n"},{"id":"50120","messageId":"f99nm6$9vi$1@sea.gmane.org","threadId":"9422","inReplyTo":"Pine.LNX.4.64.0708071257350.14781@racer.site","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2007-08-07T12:13:58Z","receivedAt":"2007-08-07T12:13:58Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":">> 100% (2295/2295) done\n>> Resolving 1793 deltas...\n>> 100% (1793/1793) done\n>> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f\n>> fatal: Not a valid object name HEAD\n> \n> I suspect that there is no master branch on the remote side, but the \n> remote's HEAD points there. Try \"git ls-remote \" to find out.\n\nI'm not too familiar with git yet, but to me this looks alright:\n\nsschuber@xp-sschuber2 ~\n$ git ls-remote git://git.kernel.org/pub/scm/qgit/qgit4.git\n6c4444edbc4b870df7cde1e05ee76d1d15ea428f HEAD\n6c4444edbc4b870df7cde1e05ee76d1d15ea428f refs/heads/master\n70cd59500e8113901333741d82bbd055f96787f6 refs/tags/qgit-2.0rc1\n1fe8ecc6a47d47a883beab1afa4607b1ca5da698 refs/tags/qgit-2.0rc1^{}\n29bb10bf0397924489a51adb759f2df4b17fc31f refs/tags/qgit-2.0rc2\n243cd78b72b1a4021d63829f62419f5483e70c7d refs/tags/qgit-2pre1\n738063eb6f0f8f706e5f8609eab003ab19628617 refs/tags/qgit-2pre1^{}\n17245c4248feab0d0425355ab5ff1cd4d7f83872 refs/tags/qgit2-pre2\n7e02b07bc910a1d49b2cb4846641e01b7f6512aa refs/tags/qgit2-pre2^{}\n\n-- \nSebastian Schuberth\n"},{"id":"50124","messageId":"f99rei$ou$1@sea.gmane.org","threadId":"9422","inReplyTo":"f99nm6$9vi$1@sea.gmane.org","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2007-08-07T13:18:10Z","receivedAt":"2007-08-07T13:18:10Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":">>> 100% (2295/2295) done\n>>> Resolving 1793 deltas...\n>>> 100% (1793/1793) done\n>>> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f\n>>> fatal: Not a valid object name HEAD\n\nAs Mark Levedahl assumed by e-mail, the problem is with Cygwin's binary \nvs. text mount mode feature. Thanks Mark.\n\nI'm running on NTFS and I did try the \"binary mount\" stuff before \"git \nclone\" by issuing\n\nmount -bc /cygdrive\n\nbut I overlooked that this command only affects /cygdrive paths, and I \ndid clone into a non /cygdrive path. So cloning to a /cygdrive mounted \npath works now.\n\nI wonder if this happens because git never passes \"b\" to any fopen() \ncalls (as there is no such thing like opening a file in binary mode \nunder Linux, because files are always opened \"binary\"). If fopen() \nsafely ignores the \"b\" option under Linux, I think it should always be \nspecified so Cygwin's git will work with text mode mounts when compiled \nfrom the original git sources.\n\n-- \nSebastian Schuberth\n"},{"id":"50132","messageId":"20070807143616.GO9527@spearce.org","threadId":"9422","inReplyTo":"f99rei$ou$1@sea.gmane.org","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-07T14:36:16Z","receivedAt":"2007-08-07T14:36:16Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sebastian Schuberth wrote:\n> I wonder if this happens because git never passes \"b\" to any fopen() \n> calls (as there is no such thing like opening a file in binary mode \n> under Linux, because files are always opened \"binary\"). If fopen() \n> safely ignores the \"b\" option under Linux, I think it should always be \n> specified so Cygwin's git will work with text mode mounts when compiled \n> from the original git sources.\n\nActually we never use fopen() when we care about the data (and we\nalways care about object data and working tree data). We always\nuse open(2) and use system call IO directly to perform all reads\nand writes. fopen() is only used on trivial things, like say the\n.git/config file.\n\nNow on a normal UNIX system open(2) *always* by definition does\nbinary IO. But Cygwin's text mount option tries to make UNIX\nprograms DOS-friendly by making all files treated as text, even if\nit supposedly doing binary IO via open(2).\n\nI think its a mis-feature of Cygwin. Git has no way (that I know\nof) to defend itself from this, other than to tell the user to make\nsure they only store a Git repository in a location that is mounted\nwith the binary flag.\n\n-- \nShawn.\n"},{"id":"50133","messageId":"20070807145825.GO21692@lavos.net","threadId":"9422","inReplyTo":"20070807143616.GO9527@spearce.org","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-08-07T14:58:25Z","receivedAt":"2007-08-07T14:58:25Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"On Tue, Aug 07, 2007 at 10:36:16AM -0400, Shawn O. Pearce wrote:\n> Now on a normal UNIX system open(2) *always* by definition does\n> binary IO. But Cygwin's text mount option tries to make UNIX\n> programs DOS-friendly by making all files treated as text, even if\n> it supposedly doing binary IO via open(2).\n> \n> I think its a mis-feature of Cygwin. Git has no way (that I know\n> of) to defend itself from this, other than to tell the user to make\n> sure they only store a Git repository in a location that is mounted\n> with the binary flag.\n\nCygwin, like Windows' own open(2) simulation, defines an O_BINARY to pass\nas a flag to open(2). I once got Git half-working on Cygwin text-mode\nmounts by doing a horrible hack approximating:\n\n#define open(name, flag, ...) \\\n\topen(name, (flag) | O_BINARY, ## __VA_ARGS__)\n\nBut it only half worked. Eventually it managed to corrupt itself again,\nand worse, the test suite was completely hopeless, as all shell activity\nstill results in text-mode files.\n\n-bcd\n"},{"id":"50135","messageId":"46B88F5A.9040801@gmail.com","threadId":"9422","inReplyTo":"20070807145825.GO21692@lavos.net","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2007-08-07T15:27:22Z","receivedAt":"2007-08-07T15:27:22Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":">> Now on a normal UNIX system open(2) *always* by definition does\n>> binary IO. But Cygwin's text mount option tries to make UNIX\n>> programs DOS-friendly by making all files treated as text, even if\n>> it supposedly doing binary IO via open(2).\n>>\n>> I think its a mis-feature of Cygwin. Git has no way (that I know\n>> of) to defend itself from this, other than to tell the user to make\n>> sure they only store a Git repository in a location that is mounted\n>> with the binary flag.\n> \n> Cygwin, like Windows' own open(2) simulation, defines an O_BINARY to pass\n> as a flag to open(2). I once got Git half-working on Cygwin text-mode\n> mounts by doing a horrible hack approximating:\n> \n> #define open(name, flag, ...) \\\n> \topen(name, (flag) | O_BINARY, ## __VA_ARGS__)\n> \n> But it only half worked. Eventually it managed to corrupt itself again,\n> and worse, the test suite was completely hopeless, as all shell activity\n> still results in text-mode files.\n\nSomething like that would have been my suggested work-around, too. \nUnfortunate to hear this alone won't fix the problem. I've spotted \nseveral fopen() calls in git where \"b\" is not explicitly used. Maybe \nfixing those, too, would to do it.\n\n-- \nSebastian Schuberth\n"},{"id":"50136","messageId":"30e4a070708070829l1ca946b6j968c14eebec06bed@mail.gmail.com","threadId":"9422","inReplyTo":"f99rei$ou$1@sea.gmane.org","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-07T15:29:23Z","receivedAt":"2007-08-07T15:29:23Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 8/7/07, Sebastian Schuberth wrote:\n> >>> 100% (2295/2295) done\n> >>> Resolving 1793 deltas...\n> >>> 100% (1793/1793) done\n> >>> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f\n> >>> fatal: Not a valid object name HEAD\n>\n>\n> I wonder if this happens because git never passes \"b\" to any fopen()\n> calls (as there is no such thing like opening a file in binary mode\n> under Linux, because files are always opened \"binary\"). If fopen()\n> safely ignores the \"b\" option under Linux, I think it should always be\n> specified so Cygwin's git will work with text mode mounts when compiled\n> from the original git sources.\n>\n> --\nIf you follow the Cygwin mailing lists, you'll find that the\ndevelopers *really* want to kill off the whole text mount thing:\nultimately, this has proved unsupportable as it requires deep\nmodifications of every tool \"ported\" over to Cygwin and invariably\nleads to strange bugs as you have just discovered. Originally, Cygwin\nhad the goal of porting Unix tools to Windows, requiring that every\ntool work on text mounts, but they restated their goal as providing a\nPOSIX environment under Windows that matches what Linux does. So, I\ndoubt you'll get support from the Cygwin developer's or the Cygwin git\nmaintainer for a text mount aware version of git. Clearly, the mingw\nport has to deal with these issues, and it might be possible to\nleverage that work for Cygwin, but the flip side is that under POSIX,\ngit explicitly recognizes the difference between \\0d\\0a and \\0a while\non a text mount, programs do not, and this would make such a ported\ngit violate the currently stated Cygwin goals.\n\nMark\n"},{"id":"50137","messageId":"66DD7425-6073-4CA8-BF01-BF07213A4804@zib.de","threadId":"9422","inReplyTo":"20070807145825.GO21692@lavos.net","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-07T17:11:31Z","receivedAt":"2007-08-07T17:11:31Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 7, 2007, at 4:58 PM, Brian Downing wrote:\n\n> But it only half worked. Eventually it managed to corrupt itself \n> again,\n> and worse, the test suite was completely hopeless, as all shell \n> activity\n> still results in text-mode files.\n\nWhy that? Although I don't fully understand the description\nof the (no)binmode CYGWIN environment variable option [1], it\nsound to me as if shells might do the right thing by default.\n\nBut wait ... further down in the document there's more magic.\n(no)tty might be related as well.\n\nMy question is, is there any chance to handle the shell\nactivity by setting the right CYGWIN options?\n\n\nHere's another idea. Could git somehow check if the file\noperations work as expected and if not refuse to work.\nGit would at least have a well defined behaviour on cygwin,\nindependently of the weird binmode/textmode stuff. Either\nit works, or it tells that it can't work.\n\nSomething like\n\nfp = fopen (\"tmp-test\", \"w\"); /* no b */\nfprintf (fp, \"\\n\");\nfclose (fp)\n\nfp = fopen (tmp-test\", \"rb\"); /* with b */\nif (freads returns crap) die;\n\nI checked a couple of cygwin installations on our machines\nand the results are quite scary. Some have all binmode,\nsome have all textmode, and some have some parts mounted\nas binmode and other as textmode. I'd not dare to recommend\nusing git on these machines.\n\n\tSteffen\n\n[1] http://www.cygwin.com/cygwin-ug-net/using-cygwinenv.html\n"},{"id":"50141","messageId":"30e4a070708071042g5623cb7ak724a8b8e588bd1da@mail.gmail.com","threadId":"9422","inReplyTo":"66DD7425-6073-4CA8-BF01-BF07213A4804@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-07T17:42:56Z","receivedAt":"2007-08-07T17:42:56Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 8/7/07, Steffen Prohaska wrote:\n>\n> My question is, is there any chance to handle the shell\n> activity by setting the right CYGWIN options?\n>\n\nSee my other message: text mounts are best considered obsolescent if\nnot deprecated, and that mode is definitely not actively developed.\nThere are just too many loopholes with forks and pipes to reliably \"do\nthe right thing.\"\n\nYour suggested tests for non-binary mode mounts (properly #ifdef'd for\nCygwin, possibly only enabled if specifically configured in) are a\nreasonable idea.\n\nMark\n"},{"id":"50143","messageId":"07BB2580-4406-496F-8ACE-F6A03D1687BE@zib.de","threadId":"9422","inReplyTo":"30e4a070708071042g5623cb7ak724a8b8e588bd1da@mail.gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-07T19:41:24Z","receivedAt":"2007-08-07T19:41:24Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"The discussion below basically leads to two questions:\n\nIs there any chance that git can be ported to cygwin's textmode?\n\nIs there any chance that patches would be accepted that try to\ndo so? Even if they add \"b\" to fopen and O_BINARY to open, which\nboth are useless on Unix?\n\nJunio, Linus?\n\nOn Aug 7, 2007, at 7:42 PM, Mark Levedahl wrote:\n\n> On 8/7/07, Steffen Prohaska wrote:\n>>\n>> My question is, is there any chance to handle the shell\n>> activity by setting the right CYGWIN options?\n>>\n>\n> See my other message: text mounts are best considered obsolescent if\n> not deprecated, and that mode is definitely not actively developed.\n> There are just too many loopholes with forks and pipes to reliably \"do\n> the right thing.\"\n\nI read your message and I just checked the most recent installer\nof cygwin (screenshot attached).\n\nI see three choices I'm offered:\n1) the path to install;\n2) install for all or just me;\n3) choose the default text file type.\n\nI wouldn't call that deprecated, not even obsolenscent. To me it\nlooks, as if the installer offers me a real choice. Besides the\ndefault path (which I never changed) and the decision whether I install\nfor all (which I would always do) I see a single real choice in this\ninstaller -- the text file type. That's far from deprecated. I am\nstrongly convinced that many consider to choose DOS/text if it offers\na benefit for them, for example if they want to run CVS in cygwin.\n\nAnd if the option to choose is around today, a reasonable assumption\nis that cygwin installations in textmode will be around for another\ncouple of years.\n\nI was convinced that git supports Windows, at least in cygwin. I am\nno longer convinced. I would no longer call this Windows support --\nnot even in cygwin. The first four people I asked to test git on\nWindows came back to me and told me that something is broken. They\ndidn't do anything wrong. They just used an option that cygwin\noffers them during installation -- not hidden, not deprecated, no\nindication that they shouldn't use this option. They or someone else\nmay have made the choice years ago. Their first impression was: git\ndoesn't work. One of them is now testing Mercurial. He explained me\ntoday: \"well, git can't even clone its own development repo. I\nrecognized that Mercurial is basically doing the same and it's\nworking fine for me.\"\n\nI'd really prefer if git handled textmode (or at least refuses to\nwork if it detects textmode).\n\n\n> Your suggested tests for non-binary mode mounts (properly #ifdef'd for\n> Cygwin, possibly only enabled if specifically configured in) are a\n> reasonable idea.\n\nWe could try to restrict that to git commands that have not proved\nto work with textmode.\n\n\tSteffen\n\n\n\n\n\n\n\n"},{"id":"50146","messageId":"alpine.LFD.0.999.0708071439021.5037@woody.linux-foundation.org","threadId":"9422","inReplyTo":"07BB2580-4406-496F-8ACE-F6A03D1687BE@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-07T21:44:21Z","receivedAt":"2007-08-07T21:44:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Aug 2007, Steffen Prohaska wrote:\n>\n> Is there any chance that patches would be accepted that try to\n> do so? Even if they add \"b\" to fopen and O_BINARY to open, which\n> both are useless on Unix?\n\nI certainly don't think it would be wrong to add O_BINARY to the open() \nparameters (and \"b\" to fopen() and friends), if it makes a difference.\n\nAdd a\n\n\t#ifndef O_BINARY\n\t#define O_BINARY 0\n\t#endif\n\nand it should be harmless anywhere else.\n\nSo if you're willing to test, and extend on this, maybe something like \nthis gets you started (I think the main issue will be the object files, \nno?)\n\n\t\tLinus\n---\ndiff --git a/sha1_file.c b/sha1_file.c\nindex aca741b..0f613c0 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -23,6 +23,10 @@\n #endif\n #endif\n \n+#ifndef O_BINARY\n+#define O_BINARY 0\n+#endif\n+\n #ifdef NO_C99_FORMAT\n #define SZ_FMT \"lu\"\n #else\n@@ -444,7 +448,7 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)\n \tstruct pack_idx_header *hdr;\n \tsize_t idx_size;\n \tuint32_t version, nr, i, *index;\n-\tint fd = open(path, O_RDONLY);\n+\tint fd = open(path, O_BINARY | O_RDONLY);\n \tstruct stat st;\n \n \tif (fd < 0)\n@@ -631,7 +635,7 @@ static int open_packed_git_1(struct packed_git *p)\n \tif (!p->index_data && open_pack_index(p))\n \t\treturn error(\"packfile %s index unavailable\", p->pack_name);\n \n-\tp->pack_fd = open(p->pack_name, O_RDONLY);\n+\tp->pack_fd = open(p->pack_name, O_BINARY | O_RDONLY);\n \tif (p->pack_fd < 0 || fstat(p->pack_fd, &st))\n \t\treturn -1;\n \n@@ -983,12 +987,12 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)\n \t\treturn NULL;\n \t}\n \n-\tfd = open(filename, O_RDONLY | sha1_file_open_flag);\n+\tfd = open(filename, O_BINARY | O_RDONLY | sha1_file_open_flag);\n \tif (fd < 0) {\n \t\t/* See if it works without O_NOATIME */\n \t\tswitch (sha1_file_open_flag) {\n \t\tdefault:\n-\t\t\tfd = open(filename, O_RDONLY);\n+\t\t\tfd = open(filename, O_BINARY | O_RDONLY);\n \t\t\tif (fd >= 0)\n \t\t\t\tbreak;\n \t\t/* Fallthrough */\n@@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)\n \treturn 0;\n }\n \n+static void close_or_die(int fd, const char *file)\n+{\n+\tif (close(fd))\n+\t\tdie(\"unable to close %s (%s)\", file, strerror(errno));\n+}\n+\n static int write_buffer(int fd, const void *buf, size_t len)\n {\n \tif (write_in_full(fd, buf, len) < 0)\n@@ -2059,7 +2069,7 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha\n \t\thashcpy(returnsha1, sha1);\n \tif (has_sha1_file(sha1))\n \t\treturn 0;\n-\tfd = open(filename, O_RDONLY);\n+\tfd = open(filename, O_BINARY | O_RDONLY);\n \tif (fd >= 0) {\n \t\t/*\n \t\t * FIXME!!! We might do collision checking here, but we'd\n@@ -2112,11 +2122,9 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha\n \n \tsize = stream.total_out;\n \n-\tif (write_buffer(fd, compressed, size) < 0)\n-\t\tdie(\"unable to write sha1 file\");\n+\twrite_or_die(fd, compressed, size);\n \tfchmod(fd, 0444);\n-\tif (close(fd))\n-\t\tdie(\"unable to write sha1 file\");\n+\tclose_or_die(fd, \"sha1 file\");\n \tfree(compressed);\n \n \treturn move_temp_to_file(tmpfile, filename);\n@@ -2229,8 +2237,7 @@ int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,\n \t\t\t\tSHA1_Update(&c, discard, sizeof(discard) -\n \t\t\t\t\t stream.avail_out);\n \t\t\t} while (stream.avail_in && ret == Z_OK);\n-\t\t\tif (write_buffer(local, buffer, *bufposn - stream.avail_in) < 0)\n-\t\t\t\tdie(\"unable to write sha1 file\");\n+\t\t\twrite_or_die(local, buffer, *bufposn - stream.avail_in);\n \t\t\tmemmove(buffer, buffer + *bufposn - stream.avail_in,\n \t\t\t\tstream.avail_in);\n \t\t\t*bufposn = stream.avail_in;\n@@ -2251,8 +2258,7 @@ int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,\n \tinflateEnd(&stream);\n \n \tfchmod(local, 0444);\n-\tif (close(local) != 0)\n-\t\tdie(\"unable to write sha1 file\");\n+\tclose_or_die(local, \"sha1 file\");\n \tSHA1_Final(real_sha1, &c);\n \tif (ret != Z_STREAM_END) {\n \t\tunlink(tmpfile);\n@@ -2412,7 +2418,7 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write\n \n \tswitch (st->st_mode & S_IFMT) {\n \tcase S_IFREG:\n-\t\tfd = open(path, O_RDONLY);\n+\t\tfd = open(path, O_BINARY | O_RDONLY);\n \t\tif (fd < 0)\n \t\t\treturn error(\"open(\\\"%s\\\"): %s\", path,\n \t\t\t\t strerror(errno));\n"},{"id":"50148","messageId":"7vir7r56cs.fsf@assigned-by-dhcp.cox.net","threadId":"9422","inReplyTo":"07BB2580-4406-496F-8ACE-F6A03D1687BE@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-07T22:26:27Z","receivedAt":"2007-08-07T22:26:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> The discussion below basically leads to two questions:\n>\n> Is there any chance that git can be ported to cygwin's textmode?\n>\n> Is there any chance that patches would be accepted that try to\n> do so? Even if they add \"b\" to fopen and O_BINARY to open, which\n> both are useless on Unix?\n>\n> Junio, Linus?\n\nHopefully fopen() would not barf upon seeing \"b\", and O_BINARY\ncan be ifdefed to 0 on platforms where it is not applicable and\nor'ed in to the flags. As long as they can be proven to be\nuseful on Cygwin, I do not see an issue.\n"},{"id":"50149","messageId":"7vejif56a2.fsf@assigned-by-dhcp.cox.net","threadId":"9422","inReplyTo":"alpine.LFD.0.999.0708071439021.5037@woody.linux-foundation.org","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-07T22:28:05Z","receivedAt":"2007-08-07T22:28:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 7 Aug 2007, Steffen Prohaska wrote:\n>>\n>> Is there any chance that patches would be accepted that try to\n>> do so? Even if they add \"b\" to fopen and O_BINARY to open, which\n>> both are useless on Unix?\n>\n> I certainly don't think it would be wrong to add O_BINARY to the open() \n> parameters (and \"b\" to fopen() and friends), if it makes a difference.\n>\n> Add a\n>\n> \t#ifndef O_BINARY\n> \t#define O_BINARY 0\n> \t#endif\n>\n> and it should be harmless anywhere else.\n\nHeh, you beat me to this --- I like it.\n\n> @@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)\n> ...\n> +static void close_or_die(int fd, const char *file)\n> +{\n> +\tif (close(fd))\n> +\t\tdie(\"unable to close %s (%s)\", file, strerror(errno));\n> +}\n> +\n\nAnd I like this even better ;-).\n"},{"id":"50151","messageId":"A80CCC35-DE1E-4A0B-9144-A8165AF6C98A@zib.de","threadId":"9422","inReplyTo":"alpine.LFD.0.999.0708071439021.5037@woody.linux-foundation.org","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-07T22:46:49Z","receivedAt":"2007-08-07T22:46:49Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 7, 2007, at 11:44 PM, Linus Torvalds wrote:\n\n>\n>\n> On Tue, 7 Aug 2007, Steffen Prohaska wrote:\n>>\n>> Is there any chance that patches would be accepted that try to\n>> do so? Even if they add \"b\" to fopen and O_BINARY to open, which\n>> both are useless on Unix?\n>\n> I certainly don't think it would be wrong to add O_BINARY to the \n> open()\n> parameters (and \"b\" to fopen() and friends), if it makes a difference.\n>\n> Add a\n>\n> \t#ifndef O_BINARY\n> \t#define O_BINARY 0\n> \t#endif\n>\n> and it should be harmless anywhere else.\n>\n> So if you're willing to test, and extend on this, maybe something like\n> this gets you started (I think the main issue will be the object \n> files,\n> no?)\n\nI took a more radical approach and used a small script to add\n\"b\" to all calls to fopen and O_BINARY to all calls to open.\nO_BINARY is provided by the Makefile if not on cygwin. I don't\nthink we need to differentiate between binary and textfiles.\nI'll send the patch shortly.\n\n\nI started to run the tests on cygwin in textmode. I chose the\nfollowing setup.\n\n- cygwin is set to binmode, that is cygwin's git is working.\n\n- I used git to cloned git to a Windows directory, say c:\\git\n and compiled there. The Windows directory is mounted in binmode.\n\n- For testing I 'mount' this directory in text mode, in my example\n\n cd /\n mkdir git-textmode\n mount --text 'c:\\git' git-textmode\n\nThis setup allows you to work with git and test in the same\nworking directory in textmode. You should double check in which\nof your directories you commit. Right now, committing in the\ntextmode directory is only for the brave ones.\n'git read-tree HEAD' in the binmode directory should help if\nyou executed the wrong git in the wrong directory and your index\ngot corrupted.\n\n\nThe first problems I ran into are pre-computed sha1's for the\ntest cases. I started to add d2u to the test scripts to generate\nfiles with unix style line endings even if cygwin is in textmode.\nThis is needed to match the expected results that come with\nthe test files. I'll send the first changes in a second patch.\nThe patch is only for illustrating the problem. It's not thought\nto be applied.\n\nThe tests are running. t0000-basic and t0010-racy-git pass. I'll\nsend a testlog later. It's running inside a virtual machine on a\nlaptop, so it may take some more time.\n\nI suspect the tests will report a lot of errors. At least all\ntests that compare 'echo' output with precomputed sha1's or\nexpected results that come with the tests should fail. I haven't\nfully understood the details of line conversion of cygwin. Some\nwork may be needed to eliminate false fails from the tests, e.g. by\nadding 'd2u', and find the real problems.\n\nI have no time to continue today.\n\n\tSteffen\n"},{"id":"50153","messageId":"11865269472595-git-send-email-prohaska@zib.de","threadId":"9422","inReplyTo":"A80CCC35-DE1E-4A0B-9144-A8165AF6C98A@zib.de","subject":"[PATCH] cygwin: added fopen \"b\" and open O_BINARY to support cygwin's textmode","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-07T22:49:06Z","receivedAt":"2007-08-07T22:49:06Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"O_BINARY = 0 is provided by the Makefile for all architectures\nexcept Cygwin.\n\nSigned-off-by: Steffen Prohaska \n---\n Makefile | 5 +++++\n attr.c | 2 +-\n builtin-apply.c | 8 ++++----\n builtin-blame.c | 4 ++--\n builtin-bundle.c | 4 ++--\n builtin-fetch--tool.c | 4 ++--\n builtin-fmt-merge-msg.c | 2 +-\n builtin-fsck.c | 2 +-\n builtin-grep.c | 4 ++--\n builtin-init-db.c | 4 ++--\n builtin-mailinfo.c | 4 ++--\n builtin-mailsplit.c | 6 +++---\n builtin-reflog.c | 2 +-\n builtin-rerere.c | 12 ++++++------\n combine-diff.c | 2 +-\n commit.c | 2 +-\n config.c | 4 ++--\n daemon.c | 4 ++--\n diff.c | 2 +-\n diffcore-order.c | 2 +-\n dir.c | 2 +-\n entry.c | 2 +-\n fast-import.c | 6 +++---\n hash-object.c | 2 +-\n http-fetch.c | 6 +++---\n http-push.c | 6 +++---\n imap-send.c | 2 +-\n index-pack.c | 6 +++---\n local-fetch.c | 6 +++---\n lockfile.c | 2 +-\n mailmap.c | 2 +-\n merge-recursive.c | 4 ++--\n pack-write.c | 2 +-\n path.c | 4 ++--\n read-cache.c | 4 ++--\n refs.c | 14 +++++++-------\n remote.c | 4 ++--\n run-command.c | 2 +-\n server-info.c | 6 +++---\n sha1_file.c | 14 +++++++-------\n shallow.c | 2 +-\n test-delta.c | 6 +++---\n trace.c | 2 +-\n 43 files changed, 95 insertions(+), 90 deletions(-)\n\nI took a more radical approach and used a small script to add\n\"b\" to all calls to fopen and O_BINARY to all calls to open.\nI don't think we need to differentiate between binary and\ntextfiles. \n\n Steffen\n\ndiff --git a/Makefile b/Makefile\nindex 2f3b9b2..0959032 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -427,6 +427,7 @@ ifeq ($(uname_O),Cygwin)\n \tNEEDS_LIBICONV = YesPlease\n \tNO_FAST_WORKING_DIRECTORY = UnfortunatelyYes\n \tNO_TRUSTABLE_FILEMODE = UnfortunatelyYes\n+\tNO_O_BINARY = YesPlease\n \t# There are conflicting reports about this.\n \t# On some boxes NO_MMAP is needed, and not so elsewhere.\n \t# Try commenting this out if you suspect MMAP is more efficient\n@@ -495,6 +496,10 @@ ifeq ($(uname_S),Darwin)\n \tendif\n endif\n \n+ifndef NO_O_BINARY\n+BASIC_CFLAGS += -DO_BINARY=0\n+endif\n+\n ifdef NO_R_TO_GCC_LINKER\n \t# Some gcc does not accept and pass -R to the linker to specify\n \t# the runtime dynamic library path.\ndiff --git a/attr.c b/attr.c\nindex a071254..442e2a6 100644\n--- a/attr.c\n+++ b/attr.c\n@@ -315,7 +315,7 @@ static struct attr_stack *read_attr_from_file(const char *path, int macro_ok)\n \tint lineno = 0;\n \n \tres = xcalloc(1, sizeof(*res));\n-\tfp = fopen(path, \"r\");\n+\tfp = fopen(path, \"rb\");\n \tif (!fp)\n \t\treturn res;\n \ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 0a0b4a9..5eecb7f 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -1467,7 +1467,7 @@ static int read_old_data(struct stat *st, const char *path, char **buf_p, unsign\n \tcase S_IFLNK:\n \t\treturn readlink(path, buf, size) != size;\n \tcase S_IFREG:\n-\t\tfd = open(path, O_RDONLY);\n+\t\tfd = open(path, O_BINARY | O_RDONLY);\n \t\tif (fd < 0)\n \t\t\treturn error(\"unable to open %s\", path);\n \t\tgot = 0;\n@@ -2404,7 +2404,7 @@ static int try_create_file(const char *path, unsigned int mode, const char *buf,\n \t\t */\n \t\treturn symlink(buf, path);\n \n-\tfd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);\n+\tfd = open(path, O_CREAT | O_EXCL | O_BINARY | O_WRONLY, (mode & 0100) ? 0777 : 0666);\n \tif (fd < 0)\n \t\treturn -1;\n \n@@ -2553,7 +2553,7 @@ static int write_out_one_reject(struct patch *patch)\n \tmemcpy(namebuf, patch->new_name, cnt);\n \tmemcpy(namebuf + cnt, \".rej\", 5);\n \n-\trej = fopen(namebuf, \"w\");\n+\trej = fopen(namebuf, \"wb\");\n \tif (!rej)\n \t\treturn error(\"cannot open %s: %s\", namebuf, strerror(errno));\n \n@@ -2866,7 +2866,7 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \t\tif (0 < prefix_length)\n \t\t\targ = prefix_filename(prefix, prefix_length, arg);\n \n-\t\tfd = open(arg, O_RDONLY);\n+\t\tfd = open(arg, O_BINARY | O_RDONLY);\n \t\tif (fd < 0)\n \t\t\tusage(apply_usage);\n \t\tread_stdin = 0;\ndiff --git a/builtin-blame.c b/builtin-blame.c\nindex 0519339..0e3b06a 100644\n--- a/builtin-blame.c\n+++ b/builtin-blame.c\n@@ -1727,7 +1727,7 @@ static int prepare_lines(struct scoreboard *sb)\n */\n static int read_ancestry(const char *graft_file)\n {\n-\tFILE *fp = fopen(graft_file, \"r\");\n+\tFILE *fp = fopen(graft_file, \"rb\");\n \tchar buf[1024];\n \tif (!fp)\n \t\treturn -1;\n@@ -2035,7 +2035,7 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con\n \t\tmode = canon_mode(st.st_mode);\n \t\tswitch (st.st_mode & S_IFMT) {\n \t\tcase S_IFREG:\n-\t\t\tfd = open(read_from, O_RDONLY);\n+\t\t\tfd = open(read_from, O_BINARY | O_RDONLY);\n \t\t\tif (fd < 0)\n \t\t\t\tdie(\"cannot open %s\", read_from);\n \t\t\tif (read_in_full(fd, buf, fin_size) != fin_size)\ndiff --git a/builtin-bundle.c b/builtin-bundle.c\nindex 6ae5ab0..4d189f5 100644\n--- a/builtin-bundle.c\n+++ b/builtin-bundle.c\n@@ -66,7 +66,7 @@ static int read_string(int fd, char *buffer, int size)\n /* returns an fd */\n static int read_header(const char *path, struct bundle_header *header) {\n \tchar buffer[1024];\n-\tint fd = open(path, O_RDONLY);\n+\tint fd = open(path, O_BINARY | O_RDONLY);\n \n \tif (fd < 0)\n \t\treturn error(\"could not open '%s'\", path);\n@@ -209,7 +209,7 @@ static int create_bundle(struct bundle_header *header, const char *path,\n \tstruct child_process rls;\n \n \tbundle_fd = (!strcmp(path, \"-\") ? 1 :\n-\t\t\topen(path, O_CREAT | O_EXCL | O_WRONLY, 0666));\n+\t\t\topen(path, O_CREAT | O_EXCL | O_BINARY | O_WRONLY, 0666));\n \tif (bundle_fd < 0)\n \t\treturn error(\"Could not create '%s': %s\", path, strerror(errno));\n \ndiff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c\nindex e2f8ede..bf0fd1f 100644\n--- a/builtin-fetch--tool.c\n+++ b/builtin-fetch--tool.c\n@@ -539,7 +539,7 @@ int cmd_fetch__tool(int argc, const char **argv, const char *prefix)\n \n \t\tif (argc != 8)\n \t\t\treturn error(\"append-fetch-head takes 6 args\");\n-\t\tfp = fopen(git_path(\"FETCH_HEAD\"), \"a\");\n+\t\tfp = fopen(git_path(\"FETCH_HEAD\"), \"ab\");\n \t\tresult = append_fetch_head(fp, argv[2], argv[3],\n \t\t\t\t\t argv[4], argv[5],\n \t\t\t\t\t argv[6], !!argv[7][0],\n@@ -553,7 +553,7 @@ int cmd_fetch__tool(int argc, const char **argv, const char *prefix)\n \n \t\tif (argc != 5)\n \t\t\treturn error(\"fetch-native-store takes 3 args\");\n-\t\tfp = fopen(git_path(\"FETCH_HEAD\"), \"a\");\n+\t\tfp = fopen(git_path(\"FETCH_HEAD\"), \"ab\");\n \t\tresult = fetch_native_store(fp, argv[2], argv[3], argv[4],\n \t\t\t\t\t verbose, force);\n \t\tfclose(fp);\ndiff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c\nindex ae60fcc..079c2d8 100644\n--- a/builtin-fmt-merge-msg.c\n+++ b/builtin-fmt-merge-msg.c\n@@ -265,7 +265,7 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)\n \t\t\t\tin = stdin;\n \t\t\telse {\n \t\t\t\tfclose(in);\n-\t\t\t\tin = fopen(argv[2], \"r\");\n+\t\t\t\tin = fopen(argv[2], \"rb\");\n \t\t\t\tif (!in)\n \t\t\t\t\tdie(\"cannot open %s\", argv[2]);\n \t\t\t}\ndiff --git a/builtin-fsck.c b/builtin-fsck.c\nindex 8d12287..335dd80 100644\n--- a/builtin-fsck.c\n+++ b/builtin-fsck.c\n@@ -150,7 +150,7 @@ static void check_unreachable_object(struct object *obj)\n \t\t\t\terror(\"Could not create lost-found\");\n \t\t\t\treturn;\n \t\t\t}\n-\t\t\tif (!(f = fopen(filename, \"w\")))\n+\t\t\tif (!(f = fopen(filename, \"wb\")))\n \t\t\t\tdie(\"Could not open %s\", filename);\n \t\t\tif (obj->type == OBJ_BLOB) {\n \t\t\t\tenum object_type type;\ndiff --git a/builtin-grep.c b/builtin-grep.c\nindex e13cb31..b941b04 100644\n--- a/builtin-grep.c\n+++ b/builtin-grep.c\n@@ -135,7 +135,7 @@ static int grep_file(struct grep_opt *opt, const char *filename)\n \tif (!S_ISREG(st.st_mode))\n \t\treturn 0;\n \tsz = xsize_t(st.st_size);\n-\ti = open(filename, O_RDONLY);\n+\ti = open(filename, O_BINARY | O_RDONLY);\n \tif (i < 0)\n \t\tgoto err_ret;\n \tdata = xmalloc(sz + 1);\n@@ -577,7 +577,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \t\t\tchar buf[1024];\n \t\t\tif (argc <= 1)\n \t\t\t\tdie(emsg_missing_argument, arg);\n-\t\t\tpatterns = fopen(argv[1], \"r\");\n+\t\t\tpatterns = fopen(argv[1], \"rb\");\n \t\t\tif (!patterns)\n \t\t\t\tdie(\"'%s': %s\", argv[1], strerror(errno));\n \t\t\twhile (fgets(buf, sizeof(buf), patterns)) {\ndiff --git a/builtin-init-db.c b/builtin-init-db.c\nindex 0d9b1e0..f9e6622 100644\n--- a/builtin-init-db.c\n+++ b/builtin-init-db.c\n@@ -33,9 +33,9 @@ static int copy_file(const char *dst, const char *src, int mode)\n \tint fdi, fdo, status;\n \n \tmode = (mode & 0111) ? 0777 : 0666;\n-\tif ((fdi = open(src, O_RDONLY)) < 0)\n+\tif ((fdi = open(src, O_BINARY | O_RDONLY)) < 0)\n \t\treturn fdi;\n-\tif ((fdo = open(dst, O_WRONLY | O_CREAT | O_EXCL, mode)) < 0) {\n+\tif ((fdo = open(dst, O_WRONLY | O_CREAT | O_BINARY | O_EXCL, mode)) < 0) {\n \t\tclose(fdi);\n \t\treturn fdo;\n \t}\ndiff --git a/builtin-mailinfo.c b/builtin-mailinfo.c\nindex b558754..d462da1 100644\n--- a/builtin-mailinfo.c\n+++ b/builtin-mailinfo.c\n@@ -905,12 +905,12 @@ static int mailinfo(FILE *in, FILE *out, int ks, const char *encoding,\n \tfin = in;\n \tfout = out;\n \n-\tcmitmsg = fopen(msg, \"w\");\n+\tcmitmsg = fopen(msg, \"wb\");\n \tif (!cmitmsg) {\n \t\tperror(msg);\n \t\treturn -1;\n \t}\n-\tpatchfile = fopen(patch, \"w\");\n+\tpatchfile = fopen(patch, \"wb\");\n \tif (!patchfile) {\n \t\tperror(patch);\n \t\tfclose(cmitmsg);\ndiff --git a/builtin-mailsplit.c b/builtin-mailsplit.c\nindex 43fc373..c04e82e 100644\n--- a/builtin-mailsplit.c\n+++ b/builtin-mailsplit.c\n@@ -61,7 +61,7 @@ static int split_one(FILE *mbox, const char *name, int allow_bare)\n \tif (is_bare && !allow_bare)\n \t\tgoto corrupt;\n \n-\tfd = open(name, O_WRONLY | O_CREAT | O_EXCL, 0666);\n+\tfd = open(name, O_WRONLY | O_CREAT | O_BINARY | O_EXCL, 0666);\n \tif (fd < 0)\n \t\tdie(\"cannot open output file %s\", name);\n \toutput = fdopen(fd, \"w\");\n@@ -135,7 +135,7 @@ static int split_maildir(const char *maildir, const char *dir,\n \tfor (i = 0; i < list.nr; i++) {\n \t\tFILE *f;\n \t\tsnprintf(file, sizeof(file), \"%s/%s\", curdir, list.items[i].path);\n-\t\tf = fopen(file, \"r\");\n+\t\tf = fopen(file, \"rb\");\n \t\tif (!f) {\n \t\t\terror(\"cannot open mail %s (%s)\", file, strerror(errno));\n \t\t\tgoto out;\n@@ -165,7 +165,7 @@ static int split_mbox(const char *file, const char *dir, int allow_bare,\n \tchar name[PATH_MAX];\n \tint ret = -1;\n \n-\tFILE *f = !strcmp(file, \"-\") ? stdin : fopen(file, \"r\");\n+\tFILE *f = !strcmp(file, \"-\") ? stdin : fopen(file, \"rb\");\n \tint file_done = 0;\n \n \tif (!f) {\ndiff --git a/builtin-reflog.c b/builtin-reflog.c\nindex ce093ca..a6221c3 100644\n--- a/builtin-reflog.c\n+++ b/builtin-reflog.c\n@@ -257,7 +257,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,\n \t\tgoto finish;\n \tif (!cmd->dry_run) {\n \t\tnewlog_path = xstrdup(git_path(\"logs/%s.lock\", ref));\n-\t\tcb.newlog = fopen(newlog_path, \"w\");\n+\t\tcb.newlog = fopen(newlog_path, \"wb\");\n \t}\n \n \tcb.ref_commit = lookup_commit_reference_gently(sha1, 1);\ndiff --git a/builtin-rerere.c b/builtin-rerere.c\nindex 29d057c..0fe2beb 100644\n--- a/builtin-rerere.c\n+++ b/builtin-rerere.c\n@@ -27,7 +27,7 @@ static void read_rr(struct path_list *rr)\n {\n \tunsigned char sha1[20];\n \tchar buf[PATH_MAX];\n-\tFILE *in = fopen(merge_rr_path, \"r\");\n+\tFILE *in = fopen(merge_rr_path, \"rb\");\n \tif (!in)\n \t\treturn;\n \twhile (fread(buf, 40, 1, in) == 1) {\n@@ -98,14 +98,14 @@ static int handle_file(const char *path,\n \tint hunk = 0, hunk_no = 0;\n \tstruct buffer minus = { NULL, 0, 0 }, plus = { NULL, 0, 0 };\n \tstruct buffer *one = &minus, *two = +\n-\tFILE *f = fopen(path, \"r\");\n+\tFILE *f = fopen(path, \"rb\");\n \tFILE *out;\n \n \tif (!f)\n \t\treturn error(\"Could not open %s\", path);\n \n \tif (output) {\n-\t\tout = fopen(output, \"w\");\n+\t\tout = fopen(output, \"wb\");\n \t\tif (!out) {\n \t\t\tfclose(f);\n \t\t\treturn error(\"Could not write %s\", output);\n@@ -201,7 +201,7 @@ static int merge(const char *name, const char *path)\n \tret = xdl_merge(&base, &cur, \"\", &other, \"\",\n \t\t\t&xpp, XDL_MERGE_ZEALOUS, &result);\n \tif (!ret) {\n-\t\tFILE *f = fopen(path, \"w\");\n+\t\tFILE *f = fopen(path, \"wb\");\n \t\tif (!f)\n \t\t\treturn error(\"Could not write to %s\", path);\n \t\tfwrite(result.ptr, result.size, 1, f);\n@@ -299,9 +299,9 @@ static int copy_file(const char *src, const char *dest)\n \tchar buffer[32768];\n \tint count;\n \n-\tif (!(in = fopen(src, \"r\")))\n+\tif (!(in = fopen(src, \"rb\")))\n \t\treturn error(\"Could not open %s\", src);\n-\tif (!(out = fopen(dest, \"w\")))\n+\tif (!(out = fopen(dest, \"wb\")))\n \t\treturn error(\"Could not open %s\", dest);\n \twhile ((count = fread(buffer, 1, sizeof(buffer), in)))\n \t\tfwrite(buffer, 1, count, out);\ndiff --git a/combine-diff.c b/combine-diff.c\nindex ef62234..cb37aea 100644\n--- a/combine-diff.c\n+++ b/combine-diff.c\n@@ -694,7 +694,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,\n \t\t\tresult[len] = 0;\n \t\t\telem->mode = canon_mode(st.st_mode);\n \t\t}\n-\t\telse if (0 <= (fd = open(elem->path, O_RDONLY)) &&\n+\t\telse if (0 <= (fd = open(elem->path, O_BINARY | O_RDONLY)) &&\n \t\t\t !fstat(fd, &st)) {\n \t\t\tsize_t len = xsize_t(st.st_size);\n \t\t\tsize_t sz = 0;\ndiff --git a/commit.c b/commit.c\nindex dc5a064..7baa1e7 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -206,7 +206,7 @@ struct commit_graft *read_graft_line(char *buf, int len)\n \n int read_graft_file(const char *graft_file)\n {\n-\tFILE *fp = fopen(graft_file, \"r\");\n+\tFILE *fp = fopen(graft_file, \"rb\");\n \tchar buf[1024];\n \tif (!fp)\n \t\treturn -1;\ndiff --git a/config.c b/config.c\nindex dd2de6e..818d444 100644\n--- a/config.c\n+++ b/config.c\n@@ -433,7 +433,7 @@ int git_default_config(const char *var, const char *value)\n int git_config_from_file(config_fn_t fn, const char *filename)\n {\n \tint ret;\n-\tFILE *f = fopen(filename, \"r\");\n+\tFILE *f = fopen(filename, \"rb\");\n \n \tret = -1;\n \tif (f) {\n@@ -784,7 +784,7 @@ int git_config_set_multivar(const char* key, const char* value,\n \t/*\n \t * If .git/config does not exist yet, write a minimal version.\n \t */\n-\tin_fd = open(config_filename, O_RDONLY);\n+\tin_fd = open(config_filename, O_BINARY | O_RDONLY);\n \tif ( in_fd < 0 ) {\n \t\tfree(store.key);\n \ndiff --git a/daemon.c b/daemon.c\nindex 9cf22fe..4d2e211 100644\n--- a/daemon.c\n+++ b/daemon.c\n@@ -956,7 +956,7 @@ static int service_loop(int socknum, int *socklist)\n /* if any standard file descriptor is missing open it to /dev/null */\n static void sanitize_stdfds(void)\n {\n-\tint fd = open(\"/dev/null\", O_RDWR, 0);\n+\tint fd = open(\"/dev/null\", O_BINARY | O_RDWR, 0);\n \twhile (fd != -1 && fd < 2)\n \t\tfd = dup(fd);\n \tif (fd == -1)\n@@ -985,7 +985,7 @@ static void daemonize(void)\n \n static void store_pid(const char *path)\n {\n-\tFILE *f = fopen(path, \"w\");\n+\tFILE *f = fopen(path, \"wb\");\n \tif (!f)\n \t\tdie(\"cannot open pid file %s: %s\", path, strerror(errno));\n \tif (fprintf(f, \"%d\\n\", getpid()) < 0 || fclose(f) != 0)\ndiff --git a/diff.c b/diff.c\nindex a5fc56b..2521bad 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -1638,7 +1638,7 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)\n \t\t\t}\n \t\t\treturn 0;\n \t\t}\n-\t\tfd = open(s->path, O_RDONLY);\n+\t\tfd = open(s->path, O_BINARY | O_RDONLY);\n \t\tif (fd < 0)\n \t\t\tgoto err_empty;\n \t\ts->data = xmmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);\ndiff --git a/diffcore-order.c b/diffcore-order.c\nindex 2a4bd82..c08226d 100644\n--- a/diffcore-order.c\n+++ b/diffcore-order.c\n@@ -19,7 +19,7 @@ static void prepare_order(const char *orderfile)\n \tif (order)\n \t\treturn;\n \n-\tfd = open(orderfile, O_RDONLY);\n+\tfd = open(orderfile, O_BINARY | O_RDONLY);\n \tif (fd < 0)\n \t\treturn;\n \tif (fstat(fd, &st)) {\ndiff --git a/dir.c b/dir.c\nindex eb6c3ab..559f728 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -144,7 +144,7 @@ static int add_excludes_from_file_1(const char *fname,\n \tsize_t size;\n \tchar *buf, *entry;\n \n-\tfd = open(fname, O_RDONLY);\n+\tfd = open(fname, O_BINARY | O_RDONLY);\n \tif (fd < 0 || fstat(fd, &st) < 0)\n \t\tgoto err;\n \tsize = xsize_t(st.st_size);\ndiff --git a/entry.c b/entry.c\nindex 0625112..02696d6 100644\n--- a/entry.c\n+++ b/entry.c\n@@ -82,7 +82,7 @@ static void remove_subtree(const char *path)\n static int create_file(const char *path, unsigned int mode)\n {\n \tmode = (mode & 0100) ? 0777 : 0666;\n-\treturn open(path, O_WRONLY | O_CREAT | O_EXCL, mode);\n+\treturn open(path, O_WRONLY | O_CREAT | O_BINARY | O_EXCL, mode);\n }\n \n static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned long *size)\ndiff --git a/fast-import.c b/fast-import.c\nindex 99a19d8..741ca41 100644\n--- a/fast-import.c\n+++ b/fast-import.c\n@@ -757,7 +757,7 @@ static char *keep_pack(char *curr_index_name)\n \n \tsnprintf(name, sizeof(name), \"%s/pack/pack-%s.keep\",\n \t\t get_object_directory(), sha1_to_hex(pack_data->sha1));\n-\tkeep_fd = open(name, O_RDWR|O_CREAT|O_EXCL, 0600);\n+\tkeep_fd = open(name, O_RDWR|O_CREAT|O_BINARY | O_EXCL, 0600);\n \tif (keep_fd < 0)\n \t\tdie(\"cannot create keep file\");\n \twrite(keep_fd, keep_msg, strlen(keep_msg));\n@@ -2109,7 +2109,7 @@ static void cmd_checkpoint(void)\n static void import_marks(const char *input_file)\n {\n \tchar line[512];\n-\tFILE *f = fopen(input_file, \"r\");\n+\tFILE *f = fopen(input_file, \"rb\");\n \tif (!f)\n \t\tdie(\"cannot read %s: %s\", input_file, strerror(errno));\n \twhile (fgets(line, sizeof(line), f)) {\n@@ -2185,7 +2185,7 @@ int main(int argc, const char **argv)\n \t\telse if (!prefixcmp(a, \"--export-pack-edges=\")) {\n \t\t\tif (pack_edges)\n \t\t\t\tfclose(pack_edges);\n-\t\t\tpack_edges = fopen(a + 20, \"a\");\n+\t\t\tpack_edges = fopen(a + 20, \"ab\");\n \t\t\tif (!pack_edges)\n \t\t\t\tdie(\"Cannot open %s: %s\", a + 20, strerror(errno));\n \t\t} else if (!strcmp(a, \"--force\"))\ndiff --git a/hash-object.c b/hash-object.c\nindex 18f5017..bb0621c 100644\n--- a/hash-object.c\n+++ b/hash-object.c\n@@ -12,7 +12,7 @@ static void hash_object(const char *path, enum object_type type, int write_objec\n \tint fd;\n \tstruct stat st;\n \tunsigned char sha1[20];\n-\tfd = open(path, O_RDONLY);\n+\tfd = open(path, O_BINARY | O_RDONLY);\n \tif (fd < 0 ||\n \t fstat(fd, &st) < 0 ||\n \t index_fd(sha1, fd, &st, write_object, type, path))\ndiff --git a/http-fetch.c b/http-fetch.c\nindex 202fae0..3a73acf 100644\n--- a/http-fetch.c\n+++ b/http-fetch.c\n@@ -171,7 +171,7 @@ static void start_object_request(struct object_request *obj_req)\n \n \t/* If a previous temp file is present, process what was already\n \t fetched. */\n-\tprevlocal = open(prevfile, O_RDONLY);\n+\tprevlocal = open(prevfile, O_BINARY | O_RDONLY);\n \tif (prevlocal != -1) {\n \t\tdo {\n \t\t\tprev_read = xread(prevlocal, prev_buf, PREV_BUF_SIZE);\n@@ -403,7 +403,7 @@ static int fetch_index(struct alt_base *repo, unsigned char *sha1)\n \n \tfilename = sha1_pack_index_name(sha1);\n \tsnprintf(tmpfile, sizeof(tmpfile), \"%s.temp\", filename);\n-\tindexfile = fopen(tmpfile, \"a\");\n+\tindexfile = fopen(tmpfile, \"ab\");\n \tif (!indexfile)\n \t\treturn error(\"Unable to open local file %s for pack index\",\n \t\t\t filename);\n@@ -763,7 +763,7 @@ static int fetch_pack(struct alt_base *repo, unsigned char *sha1)\n \n \tfilename = sha1_pack_name(target->sha1);\n \tsnprintf(tmpfile, sizeof(tmpfile), \"%s.temp\", filename);\n-\tpackfile = fopen(tmpfile, \"a\");\n+\tpackfile = fopen(tmpfile, \"ab\");\n \tif (!packfile)\n \t\treturn error(\"Unable to open local file %s for pack\",\n \t\t\t filename);\ndiff --git a/http-push.c b/http-push.c\nindex 7c3720f..921960f 100644\n--- a/http-push.c\n+++ b/http-push.c\n@@ -286,7 +286,7 @@ static void start_fetch_loose(struct transfer_request *request)\n \n \t/* If a previous temp file is present, process what was already\n \t fetched. */\n-\tprevlocal = open(prevfile, O_RDONLY);\n+\tprevlocal = open(prevfile, O_BINARY | O_RDONLY);\n \tif (prevlocal != -1) {\n \t\tdo {\n \t\t\tprev_read = xread(prevlocal, prev_buf, PREV_BUF_SIZE);\n@@ -430,7 +430,7 @@ static void start_fetch_packed(struct transfer_request *request)\n \t\tcheck_request = check_request->next;\n \t}\n \n-\tpackfile = fopen(request->tmpfile, \"a\");\n+\tpackfile = fopen(request->tmpfile, \"ab\");\n \tif (!packfile) {\n \t\tfprintf(stderr, \"Unable to open local file %s for pack\",\n \t\t\tfilename);\n@@ -949,7 +949,7 @@ static int fetch_index(unsigned char *sha1)\n \n \tfilename = sha1_pack_index_name(sha1);\n \tsnprintf(tmpfile, sizeof(tmpfile), \"%s.temp\", filename);\n-\tindexfile = fopen(tmpfile, \"a\");\n+\tindexfile = fopen(tmpfile, \"ab\");\n \tif (!indexfile)\n \t\treturn error(\"Unable to open local file %s for pack index\",\n \t\t\t filename);\ndiff --git a/imap-send.c b/imap-send.c\nindex a5a0696..1aab483 100644\n--- a/imap-send.c\n+++ b/imap-send.c\n@@ -386,7 +386,7 @@ arc4_init( void )\n \tint i, fd;\n \tunsigned char j, si, dat[128];\n \n-\tif ((fd = open( \"/dev/urandom\", O_RDONLY )) < 0 && (fd = open( \"/dev/random\", O_RDONLY )) < 0) {\n+\tif ((fd = open( \"/dev/urandom\", O_RDONLY )) < 0 && (fd = open( \"/dev/random\", O_BINARY | O_RDONLY )) < 0) {\n \t\tfprintf( stderr, \"Fatal: no random number source available.\\n\" );\n \t\texit( 3 );\n \t}\ndiff --git a/index-pack.c b/index-pack.c\nindex 8403c36..f6e65a4 100644\n--- a/index-pack.c\n+++ b/index-pack.c\n@@ -117,12 +117,12 @@ static const char *open_pack_file(const char *pack_name)\n \t\t\toutput_fd = mkstemp(tmpfile);\n \t\t\tpack_name = xstrdup(tmpfile);\n \t\t} else\n-\t\t\toutput_fd = open(pack_name, O_CREAT|O_EXCL|O_RDWR, 0600);\n+\t\t\toutput_fd = open(pack_name, O_CREAT|O_EXCL|O_BINARY | O_RDWR, 0600);\n \t\tif (output_fd < 0)\n \t\t\tdie(\"unable to create %s: %s\\n\", pack_name, strerror(errno));\n \t\tpack_fd = output_fd;\n \t} else {\n-\t\tinput_fd = open(pack_name, O_RDONLY);\n+\t\tinput_fd = open(pack_name, O_BINARY | O_RDONLY);\n \t\tif (input_fd < 0)\n \t\t\tdie(\"cannot open packfile '%s': %s\",\n \t\t\t pack_name, strerror(errno));\n@@ -625,7 +625,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,\n \t\t\t\t get_object_directory(), sha1_to_hex(sha1));\n \t\t\tkeep_name = name;\n \t\t}\n-\t\tkeep_fd = open(keep_name, O_RDWR|O_CREAT|O_EXCL, 0600);\n+\t\tkeep_fd = open(keep_name, O_RDWR|O_CREAT|O_BINARY | O_EXCL, 0600);\n \t\tif (keep_fd < 0) {\n \t\t\tif (errno != EEXIST)\n \t\t\t\tdie(\"cannot write keep file\");\ndiff --git a/local-fetch.c b/local-fetch.c\nindex bf7ec6c..deac558 100644\n--- a/local-fetch.c\n+++ b/local-fetch.c\n@@ -85,13 +85,13 @@ static int copy_file(const char *source, char *dest, const char *hex,\n \tif (use_filecopy) {\n \t\tint ifd, ofd, status = 0;\n \n-\t\tifd = open(source, O_RDONLY);\n+\t\tifd = open(source, O_BINARY | O_RDONLY);\n \t\tif (ifd < 0) {\n \t\t\tif (!warn_if_not_exists && errno == ENOENT)\n \t\t\t\treturn -1;\n \t\t\treturn error(\"cannot open %s\", source);\n \t\t}\n-\t\tofd = open(dest, O_WRONLY | O_CREAT | O_EXCL, 0666);\n+\t\tofd = open(dest, O_WRONLY | O_CREAT | O_BINARY | O_EXCL, 0666);\n \t\tif (ofd < 0) {\n \t\t\tclose(ifd);\n \t\t\treturn error(\"cannot open %s\", dest);\n@@ -173,7 +173,7 @@ int fetch_ref(char *ref, unsigned char *sha1)\n \t\tref_name_start = strlen(filename);\n \t}\n \tstrcpy(filename + ref_name_start, ref);\n-\tifd = open(filename, O_RDONLY);\n+\tifd = open(filename, O_BINARY | O_RDONLY);\n \tif (ifd < 0) {\n \t\tclose(ifd);\n \t\treturn error(\"cannot open %s\", filename);\ndiff --git a/lockfile.c b/lockfile.c\nindex 9a1f64d..680c2fd 100644\n--- a/lockfile.c\n+++ b/lockfile.c\n@@ -130,7 +130,7 @@ static int lock_file(struct lock_file *lk, const char *path)\n \t */\n \tresolve_symlink(lk->filename, sizeof(lk->filename)-5);\n \tstrcat(lk->filename, \".lock\");\n-\tfd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);\n+\tfd = open(lk->filename, O_RDWR | O_CREAT | O_BINARY | O_EXCL, 0666);\n \tif (0 <= fd) {\n \t\tif (!lock_file_list) {\n \t\t\tsignal(SIGINT, remove_lock_file_on_signal);\ndiff --git a/mailmap.c b/mailmap.c\nindex 8714167..685dd9d 100644\n--- a/mailmap.c\n+++ b/mailmap.c\n@@ -5,7 +5,7 @@\n int read_mailmap(struct path_list *map, const char *filename, char **repo_abbrev)\n {\n \tchar buffer[1024];\n-\tFILE *f = fopen(filename, \"r\");\n+\tFILE *f = fopen(filename, \"rb\");\n \n \tif (f == NULL)\n \t\treturn 1;\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex c8539ec..2d44d89 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -590,7 +590,7 @@ static void update_file_flags(const unsigned char *sha,\n \t\t\t\tmode = 0777;\n \t\t\telse\n \t\t\t\tmode = 0666;\n-\t\t\tfd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);\n+\t\t\tfd = open(path, O_WRONLY | O_TRUNC | O_BINARY | O_CREAT, mode);\n \t\t\tif (fd < 0)\n \t\t\t\tdie(\"failed to open %s: %s\", path, strerror(errno));\n \t\t\tflush_buffer(fd, buf, size);\n@@ -831,7 +831,7 @@ static int ll_ext_merge(const struct ll_merge_driver *fn,\n \t\t; /* failure in run-command */\n \telse\n \t\tstatus = -status;\n-\tfd = open(temp[1], O_RDONLY);\n+\tfd = open(temp[1], O_BINARY | O_RDONLY);\n \tif (fd < 0)\n \t\tgoto bad;\n \tif (fstat(fd, &st))\ndiff --git a/pack-write.c b/pack-write.c\nindex 1cf5f7c..9abbd33 100644\n--- a/pack-write.c\n+++ b/pack-write.c\n@@ -49,7 +49,7 @@ const char *write_idx_file(const char *index_name, struct pack_idx_entry **objec\n \t\tindex_name = xstrdup(tmpfile);\n \t} else {\n \t\tunlink(index_name);\n-\t\tfd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n+\t\tfd = open(index_name, O_CREAT|O_EXCL|O_BINARY | O_WRONLY, 0600);\n \t}\n \tif (fd < 0)\n \t\tdie(\"unable to create %s: %s\", index_name, strerror(errno));\ndiff --git a/path.c b/path.c\nindex 4260952..7707729 100644\n--- a/path.c\n+++ b/path.c\n@@ -6,7 +6,7 @@\n * It's obviously not thread-safe. Sue me. But it's quite\n * useful for doing things like\n *\n- * f = open(mkpath(\"%s/%s.git\", base, name), O_RDONLY);\n+ * f = open(mkpath(\"%s/%s.git\", base, name), O_BINARY | O_RDONLY);\n *\n * which is what it's designed for.\n */\n@@ -107,7 +107,7 @@ int validate_headref(const char *path)\n \t/*\n \t * Anything else, just open it and try to see if it is a symbolic ref.\n \t */\n-\tfd = open(path, O_RDONLY);\n+\tfd = open(path, O_BINARY | O_RDONLY);\n \tif (fd < 0)\n \t\treturn -1;\n \tlen = read_in_full(fd, buffer, sizeof(buffer)-1);\ndiff --git a/read-cache.c b/read-cache.c\nindex e060392..659b1ef 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -48,7 +48,7 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)\n static int ce_compare_data(struct cache_entry *ce, struct stat *st)\n {\n \tint match = -1;\n-\tint fd = open(ce->name, O_RDONLY);\n+\tint fd = open(ce->name, O_BINARY | O_RDONLY);\n \n \tif (fd >= 0) {\n \t\tunsigned char sha1[20];\n@@ -894,7 +894,7 @@ int read_index_from(struct index_state *istate, const char *path)\n \n \terrno = ENOENT;\n \tistate->timestamp = 0;\n-\tfd = open(path, O_RDONLY);\n+\tfd = open(path, O_BINARY | O_RDONLY);\n \tif (fd < 0) {\n \t\tif (errno == ENOENT)\n \t\t\treturn 0;\ndiff --git a/refs.c b/refs.c\nindex fac6548..5d1937f 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -216,7 +216,7 @@ static void read_packed_refs(FILE *f, struct cached_refs *cached_refs)\n static struct ref_list *get_packed_refs(void)\n {\n \tif (!cached_refs.did_packed) {\n-\t\tFILE *f = fopen(git_path(\"packed-refs\"), \"r\");\n+\t\tFILE *f = fopen(git_path(\"packed-refs\"), \"rb\");\n \t\tcached_refs.packed = NULL;\n \t\tif (f) {\n \t\t\tread_packed_refs(f, &cached_refs);\n@@ -293,7 +293,7 @@ static int resolve_gitlink_packed_ref(char *name, int pathlen, const char *refna\n \tint retval;\n \n \tstrcpy(name + pathlen, \"packed-refs\");\n-\tf = fopen(name, \"r\");\n+\tf = fopen(name, \"rb\");\n \tif (!f)\n \t\treturn -1;\n \tread_packed_refs(f, &refs);\n@@ -320,7 +320,7 @@ static int resolve_gitlink_ref_recursive(char *name, int pathlen, const char *re\n \tif (recursion > MAXDEPTH || len > MAXREFLEN)\n \t\treturn -1;\n \tmemcpy(name + pathlen, refname, len+1);\n-\tfd = open(name, O_RDONLY);\n+\tfd = open(name, O_BINARY | O_RDONLY);\n \tif (fd < 0)\n \t\treturn resolve_gitlink_packed_ref(name, pathlen, refname, result);\n \n@@ -429,7 +429,7 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *\n \t\t * Anything else, just open it and try to use it as\n \t\t * a ref\n \t\t */\n-\t\tfd = open(path, O_RDONLY);\n+\t\tfd = open(path, O_BINARY | O_RDONLY);\n \t\tif (fd < 0)\n \t\t\treturn NULL;\n \t\tlen = read_in_full(fd, buffer, sizeof(buffer)-1);\n@@ -1209,7 +1209,7 @@ int create_symref(const char *ref_target, const char *refs_heads_master,\n \t\tgoto error_free_return;\n \t}\n \tlockpath = mkpath(\"%s.lock\", git_HEAD);\n-\tfd = open(lockpath, O_CREAT | O_EXCL | O_WRONLY, 0666);\n+\tfd = open(lockpath, O_CREAT | O_EXCL | O_BINARY | O_WRONLY, 0666);\n \tif (fd < 0) {\n \t\terror(\"Unable to open %s for writing\", lockpath);\n \t\tgoto error_free_return;\n@@ -1268,7 +1268,7 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *\n \tsize_t mapsz;\n \n \tlogfile = git_path(\"logs/%s\", ref);\n-\tlogfd = open(logfile, O_RDONLY, 0);\n+\tlogfd = open(logfile, O_BINARY | O_RDONLY, 0);\n \tif (logfd < 0)\n \t\tdie(\"Unable to read log %s: %s\", logfile, strerror(errno));\n \tfstat(logfd, &st);\n@@ -1366,7 +1366,7 @@ int for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data)\n \tint ret = 0;\n \n \tlogfile = git_path(\"logs/%s\", ref);\n-\tlogfp = fopen(logfile, \"r\");\n+\tlogfp = fopen(logfile, \"rb\");\n \tif (!logfp)\n \t\treturn -1;\n \twhile (fgets(buf, sizeof(buf), logfp)) {\ndiff --git a/remote.c b/remote.c\nindex bb774d0..f7c1644 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -69,7 +69,7 @@ static struct remote *make_remote(const char *name, int len)\n \n static void read_remotes_file(struct remote *remote)\n {\n-\tFILE *f = fopen(git_path(\"remotes/%s\", remote->name), \"r\");\n+\tFILE *f = fopen(git_path(\"remotes/%s\", remote->name), \"rb\");\n \n \tif (!f)\n \t\treturn;\n@@ -117,7 +117,7 @@ static void read_branches_file(struct remote *remote)\n {\n \tconst char *slash = strchr(remote->name, '/');\n \tint n = slash ? slash - remote->name : 1000;\n-\tFILE *f = fopen(git_path(\"branches/%.*s\", n, remote->name), \"r\");\n+\tFILE *f = fopen(git_path(\"branches/%.*s\", n, remote->name), \"rb\");\n \tchar *s, *p;\n \tint len;\n \ndiff --git a/run-command.c b/run-command.c\nindex 7e779d3..72c47d3 100644\n--- a/run-command.c\n+++ b/run-command.c\n@@ -10,7 +10,7 @@ static inline void close_pair(int fd[2])\n \n static inline void dup_devnull(int to)\n {\n-\tint fd = open(\"/dev/null\", O_RDWR);\n+\tint fd = open(\"/dev/null\", O_BINARY | O_RDWR);\n \tdup2(fd, to);\n \tclose(fd);\n }\ndiff --git a/server-info.c b/server-info.c\nindex 0d1312c..a096025 100644\n--- a/server-info.c\n+++ b/server-info.c\n@@ -33,7 +33,7 @@ static int update_info_refs(int force)\n \tstrcpy(path1 + len, \"+\");\n \n \tsafe_create_leading_directories(path0);\n-\tinfo_ref_fp = fopen(path1, \"w\");\n+\tinfo_ref_fp = fopen(path1, \"wb\");\n \tif (!info_ref_fp)\n \t\treturn error(\"unable to update %s\", path0);\n \tfor_each_ref(add_info_ref, NULL);\n@@ -95,7 +95,7 @@ static int read_pack_info_file(const char *infofile)\n \tchar line[1000];\n \tint old_cnt = 0;\n \n-\tfp = fopen(infofile, \"r\");\n+\tfp = fopen(infofile, \"rb\");\n \tif (!fp)\n \t\treturn 1; /* nonexistent is not an error. */\n \n@@ -223,7 +223,7 @@ static int update_info_packs(int force)\n \tinit_pack_info(infofile, force);\n \n \tsafe_create_leading_directories(name);\n-\tfp = fopen(name, \"w\");\n+\tfp = fopen(name, \"wb\");\n \tif (!fp)\n \t\treturn error(\"cannot open %s\", name);\n \twrite_pack_info_file(fp);\ndiff --git a/sha1_file.c b/sha1_file.c\nindex aca741b..9866aa9 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -360,7 +360,7 @@ static void read_info_alternates(const char * relative_base, int depth)\n \tint fd;\n \n \tsprintf(path, \"%s/%s\", relative_base, alt_file_name);\n-\tfd = open(path, O_RDONLY);\n+\tfd = open(path, O_BINARY | O_RDONLY);\n \tif (fd < 0)\n \t\treturn;\n \tif (fstat(fd, &st) || (st.st_size == 0)) {\n@@ -444,7 +444,7 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)\n \tstruct pack_idx_header *hdr;\n \tsize_t idx_size;\n \tuint32_t version, nr, i, *index;\n-\tint fd = open(path, O_RDONLY);\n+\tint fd = open(path, O_BINARY | O_RDONLY);\n \tstruct stat st;\n \n \tif (fd < 0)\n@@ -631,7 +631,7 @@ static int open_packed_git_1(struct packed_git *p)\n \tif (!p->index_data && open_pack_index(p))\n \t\treturn error(\"packfile %s index unavailable\", p->pack_name);\n \n-\tp->pack_fd = open(p->pack_name, O_RDONLY);\n+\tp->pack_fd = open(p->pack_name, O_BINARY | O_RDONLY);\n \tif (p->pack_fd < 0 || fstat(p->pack_fd, &st))\n \t\treturn -1;\n \n@@ -983,12 +983,12 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)\n \t\treturn NULL;\n \t}\n \n-\tfd = open(filename, O_RDONLY | sha1_file_open_flag);\n+\tfd = open(filename, O_BINARY | O_RDONLY | sha1_file_open_flag);\n \tif (fd < 0) {\n \t\t/* See if it works without O_NOATIME */\n \t\tswitch (sha1_file_open_flag) {\n \t\tdefault:\n-\t\t\tfd = open(filename, O_RDONLY);\n+\t\t\tfd = open(filename, O_BINARY | O_RDONLY);\n \t\t\tif (fd >= 0)\n \t\t\t\tbreak;\n \t\t/* Fallthrough */\n@@ -2059,7 +2059,7 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha\n \t\thashcpy(returnsha1, sha1);\n \tif (has_sha1_file(sha1))\n \t\treturn 0;\n-\tfd = open(filename, O_RDONLY);\n+\tfd = open(filename, O_BINARY | O_RDONLY);\n \tif (fd >= 0) {\n \t\t/*\n \t\t * FIXME!!! We might do collision checking here, but we'd\n@@ -2412,7 +2412,7 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write\n \n \tswitch (st->st_mode & S_IFMT) {\n \tcase S_IFREG:\n-\t\tfd = open(path, O_RDONLY);\n+\t\tfd = open(path, O_BINARY | O_RDONLY);\n \t\tif (fd < 0)\n \t\t\treturn error(\"open(\\\"%s\\\"): %s\", path,\n \t\t\t\t strerror(errno));\ndiff --git a/shallow.c b/shallow.c\nindex dbd9f5a..b31020b 100644\n--- a/shallow.c\n+++ b/shallow.c\n@@ -25,7 +25,7 @@ int is_repository_shallow(void)\n \tif (is_shallow >= 0)\n \t\treturn is_shallow;\n \n-\tfp = fopen(git_path(\"shallow\"), \"r\");\n+\tfp = fopen(git_path(\"shallow\"), \"rb\");\n \tif (!fp) {\n \t\tis_shallow = 0;\n \t\treturn is_shallow;\ndiff --git a/test-delta.c b/test-delta.c\nindex 3d885ff..53011a4 100644\n--- a/test-delta.c\n+++ b/test-delta.c\n@@ -27,7 +27,7 @@ int main(int argc, char *argv[])\n \t\treturn 1;\n \t}\n \n-\tfd = open(argv[2], O_RDONLY);\n+\tfd = open(argv[2], O_BINARY | O_RDONLY);\n \tif (fd < 0 || fstat(fd, &st)) {\n \t\tperror(argv[2]);\n \t\treturn 1;\n@@ -41,7 +41,7 @@ int main(int argc, char *argv[])\n \t}\n \tclose(fd);\n \n-\tfd = open(argv[3], O_RDONLY);\n+\tfd = open(argv[3], O_BINARY | O_RDONLY);\n \tif (fd < 0 || fstat(fd, &st)) {\n \t\tperror(argv[3]);\n \t\treturn 1;\n@@ -68,7 +68,7 @@ int main(int argc, char *argv[])\n \t\treturn 1;\n \t}\n \n-\tfd = open (argv[4], O_WRONLY|O_CREAT|O_TRUNC, 0666);\n+\tfd = open (argv[4], O_WRONLY|O_CREAT|O_BINARY | O_TRUNC, 0666);\n \tif (fd < 0 || write_in_full(fd, out_buf, out_size) != out_size) {\n \t\tperror(argv[4]);\n \t\treturn 1;\ndiff --git a/trace.c b/trace.c\nindex 7961a27..b8c6a44 100644\n--- a/trace.c\n+++ b/trace.c\n@@ -65,7 +65,7 @@ static int get_trace_fd(int *need_close)\n \tif (strlen(trace) == 1 && isdigit(*trace))\n \t\treturn atoi(trace);\n \tif (*trace == '/') {\n-\t\tint fd = open(trace, O_WRONLY | O_APPEND | O_CREAT, 0666);\n+\t\tint fd = open(trace, O_WRONLY | O_APPEND | O_BINARY | O_CREAT, 0666);\n \t\tif (fd == -1) {\n \t\t\tfprintf(stderr,\n \t\t\t\t\"Could not open '%s' for tracing: %s\\n\"\n-- \n1.5.1.2\n"},{"id":"50155","messageId":"11865269472121-git-send-email-prohaska@zib.de","threadId":"9422","inReplyTo":"11865269472595-git-send-email-prohaska@zib.de","subject":"[PATCH] tests: added d2u to have unix style testfiles even in textmode","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-07T22:49:07Z","receivedAt":"2007-08-07T22:49:07Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"This is needed if the content of files is compared with\nprecomputed sha1s or stored expected results.\n\n***WARNING***\nThis patch is useful for testing and illustrating the problem\nbut not thought to be applied to any official git branch.\n\nSigned-off-by: Steffen Prohaska \n---\n t/t0000-basic.sh | 2 +-\n t/t0020-crlf.sh | 8 ++++----\n t/t0021-conversion.sh | 4 ++--\n 3 files changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex 4e49d59..bf71ce6 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -91,7 +91,7 @@ test_expect_success \\\n mkdir path2 path3 path3/subp3\n for p in path0 path2/file2 path3/file3 path3/subp3/file3\n do\n- echo \"hello $p\" >$p\n+ echo \"hello $p\" | d2u >$p\n ln -s \"hello $p\" ${p}sym\n done\n test_expect_success \\\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex fe1dfd0..52dc739 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -21,10 +21,10 @@ test_expect_success setup '\n \n \tgit repo-config core.autocrlf false &&\n \n-\tfor w in Hello world how are you; do echo $w; done >one &&\n+\tfor w in Hello world how are you; do echo $w; done | d2u >one &&\n \tmkdir dir &&\n-\tfor w in I am very very fine thank you; do echo $w; done >dir/two &&\n-\tfor w in Oh here is NULQin text here; do echo $w; done | q_to_nul >three &&\n+\tfor w in I am very very fine thank you; do echo $w; done | d2u >dir/two &&\n+\tfor w in Oh here is NULQin text here; do echo $w; done | q_to_nul | d2u >three &&\n \tgit add . &&\n \n \tgit commit -m initial &&\n@@ -34,7 +34,7 @@ test_expect_success setup '\n \ttwo=`git rev-parse HEAD:dir/two` &&\n \tthree=`git rev-parse HEAD:three` &&\n \n-\tfor w in Some extra lines here; do echo $w; done >>one &&\n+\tfor w in Some extra lines here; do echo $w; done | d2u >>one &&\n \tgit diff >patch.file &&\n \tpatched=`git hash-object --stdin expanded-keywords &&\n+\t} | d2u > expanded-keywords &&\n \n \t{\n \t\techo \"File with expanded keywords\"\n@@ -68,7 +68,7 @@ test_expect_success expanded_in_repo '\n \t\techo \"\\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \\$\"\n \t\techo \"\\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \\$\"\n \t\techo \"\\$Id: NoTerminatingSymbol\"\n-\t} > expected-output &&\n+\t} | d2u > expected-output &&\n \n \tgit add expanded-keywords &&\n \tgit commit -m \"File with keywords expanded\" &&\n-- \n1.5.1.2\n"},{"id":"50157","messageId":"16E4650F-5046-4F8D-A88B-2AE48BC5E446@zib.de","threadId":"9422","inReplyTo":"A80CCC35-DE1E-4A0B-9144-A8165AF6C98A@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-07T23:20:14Z","receivedAt":"2007-08-07T23:20:14Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"I apologize, I didn't check the size of the attachment\nin the previous mail (which probably got blocked from\nthe list).\n\nThis time with a link to the logfile.\n\n\nOn Aug 8, 2007, at 12:46 AM, Steffen Prohaska wrote:\n\n> The tests are running. t0000-basic and t0010-racy-git pass. I'll\n> send a testlog later. It's running inside a virtual machine on a\n> laptop, so it may take some more time.\n>\n> I suspect the tests will report a lot of errors. At least all\n> tests that compare 'echo' output with precomputed sha1's or\n> expected results that come with the tests should fail. I haven't\n> fully understood the details of line conversion of cygwin. Some\n> work may be needed to eliminate false fails from the tests, e.g. by\n> adding 'd2u', and find the real problems.\n\nI attached the log of a testrun on an textmode mounted directory\nin cygwin with the two recently sent patches applied.\n\nIt doesn't look too bad, but it's far from perfect:\n\n1470 ok to 637 FAIL\n\nhttp://www.zib.de/prohaska/hidden/2007/git-cygwin-textmode/ \ntestlog-2007-08-08.txt\n\n\tSteffen\n"},{"id":"50164","messageId":"alpine.LFD.0.999.0708071959470.23971@woody.linux-foundation.org","threadId":"9422","inReplyTo":"11865269472121-git-send-email-prohaska@zib.de","subject":"Re: [PATCH] tests: added d2u to have unix style testfiles even in textmode","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-08T03:03:03Z","receivedAt":"2007-08-08T03:03:03Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 8 Aug 2007, Steffen Prohaska wrote:\n>\n> This is needed if the content of files is compared with\n> precomputed sha1s or stored expected results.\n> \n> ***WARNING***\n> This patch is useful for testing and illustrating the problem\n> but not thought to be applied to any official git branch.\n\nQuite frankly, *much* rather than having d2u everywhere, why not make the \ndefault for DOS/Windows be to have\n\n\t[core]\n\t\tautocrlf=true\n\nand then none of this should hopefully be needed.\n\n(We still need to write the internal git objects using O_BINARY to make \nsure that cygwin doesn't corrupt binary data, but that's a totally \ndifferent issue).\n\n\t\t\tLinus\n"},{"id":"50168","messageId":"alpine.LFD.0.999.0708072045260.25146@woody.linux-foundation.org","threadId":"9422","inReplyTo":"7vejif56a2.fsf@assigned-by-dhcp.cox.net","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-08T03:47:24Z","receivedAt":"2007-08-08T03:47:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Aug 2007, Junio C Hamano wrote:\n> \n> > @@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)\n> > ...\n> > +static void close_or_die(int fd, const char *file)\n> > +{\n> > +\tif (close(fd))\n> > +\t\tdie(\"unable to close %s (%s)\", file, strerror(errno));\n> > +}\n> > +\n> \n> And I like this even better ;-).\n\nGaah, that was unintentional. Just random noise I had in my tree, and \ndidn't even realize made it into the patch.\n\nThat \"close_or_die()\" was because I saw somebody report a write error \nwithout the error string, apparently because the error only got reported \non the close (probably NFS). This way you see if the reason the close \nfailed was due to out of diskspace or whatever.\n\nBut I should have split them up properly - the close_or_die() part \nobviously had nothing to do with the O_BINARY part. Feel free to take it \nregardless, or split it yourself.\n\n\t\tLinus\n"},{"id":"50170","messageId":"20070808042513.GP21692@lavos.net","threadId":"9422","inReplyTo":"A80CCC35-DE1E-4A0B-9144-A8165AF6C98A@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-08-08T04:25:13Z","receivedAt":"2007-08-08T04:25:13Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"On Wed, Aug 08, 2007 at 12:46:49AM +0200, Steffen Prohaska wrote:\n> I started to run the tests on cygwin in textmode. I chose the\n> following setup.\n\nIn addition to all the other stuff discussed, I believe you also need\nto worry about the binaryness of stdin and stdout.\n\nLooking at:\n\nhttp://www.cygwin.com/cygwin-ug-net/using-textbinary.html\n\nI think this can be achieved by putting something like:\n\n\tsetmode(0, O_BINARY);\n\tsetmode(1, O_BINARY);\n\nat the start of git's main().\n\nWhen I was trying to get this to work, I did this as well as fixing up\nopen() and fopen() calls as has already been discussed. What got me\nto quit, however, was that I never found a decent way to make the Git\nshell scripts binary safe, and enough of the system was in shell as to\nmake it pretty much useless for everyday use.\n\nLooking at the examples on the above page:\n\n To illustrate the various rules, we provide scripts to delete CRs from\n files by using the tr program, which can only write to standard output.\n The script\n\n #!/bin/sh\n # Remove \\r from the file given as argument\n tr -d '\\r' < \"$1\" > \"$1\".nocr\n\n will not work on a text mounted systems because the \\r will be\n reintroduced on writing. However scripts such as\n\n #!/bin/sh\n # Remove \\r from the file given as argument\n tr -d '\\r' | gzip | gunzip > \"$1\".nocr\n\n work fine. In the first case (assuming the pipes are binary) we rely\n on gunzip to set its output to binary mode, possibly overriding the\n mode used by the shell.\n\nwas all it took to convince me this was probably a fool's errand.\n\nI wound up fixing our software so it would build on a binary mount,\nwhich I decided was a much more sane solution.\n\n-bcd\n"},{"id":"50171","messageId":"98CEB25C-A1ED-4F6C-B6F4-70310B819C1E@zib.de","threadId":"9422","inReplyTo":"alpine.LFD.0.999.0708071959470.23971@woody.linux-foundation.org","subject":"Re: [PATCH] tests: added d2u to have unix style testfiles even in textmode","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-08T05:00:09Z","receivedAt":"2007-08-08T05:00:09Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 8, 2007, at 5:03 AM, Linus Torvalds wrote:\n\n> On Wed, 8 Aug 2007, Steffen Prohaska wrote:\n>>\n>> This is needed if the content of files is compared with\n>> precomputed sha1s or stored expected results.\n>>\n>> ***WARNING***\n>> This patch is useful for testing and illustrating the problem\n>> but not thought to be applied to any official git branch.\n>\n> Quite frankly, *much* rather than having d2u everywhere, why not \n> make the\n> default for DOS/Windows be to have\n>\n> \t[core]\n> \t\tautocrlf=true\n>\n> and then none of this should hopefully be needed.\n\nThanks for that idea. I'll check how far I can get with it.\n\n\tSteffen\n"},{"id":"50173","messageId":"11631546-D4E4-491A-8A12-98A42043C535@zib.de","threadId":"9422","inReplyTo":"20070808042513.GP21692@lavos.net","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-08T05:46:18Z","receivedAt":"2007-08-08T05:46:18Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 8, 2007, at 6:25 AM, Brian Downing wrote:\n\n> On Wed, Aug 08, 2007 at 12:46:49AM +0200, Steffen Prohaska wrote:\n>> I started to run the tests on cygwin in textmode. I chose the\n>> following setup.\n>\n> In addition to all the other stuff discussed, I believe you also need\n> to worry about the binaryness of stdin and stdout.\n>\n> Looking at:\n>\n> http://www.cygwin.com/cygwin-ug-net/using-textbinary.html\n>\n> I think this can be achieved by putting something like:\n>\n> \tsetmode(0, O_BINARY);\n> \tsetmode(1, O_BINARY);\n>\n> at the start of git's main().\n\nI agree. This is my understanding as well.\n\n> When I was trying to get this to work, I did this as well as fixing up\n> open() and fopen() calls as has already been discussed. What got me\n> to quit, however, was that I never found a decent way to make the Git\n> shell scripts binary safe, and enough of the system was in shell as to\n> make it pretty much useless for everyday use.\n\nDid you find a way, maybe not as decent as you wished?\n\n\n> Looking at the examples on the above page:\n>\n> To illustrate the various rules, we provide scripts to delete \n> CRs from\n> files by using the tr program, which can only write to standard \n> output.\n> The script\n>\n> #!/bin/sh\n> # Remove \\r from the file given as argument\n> tr -d '\\r' < \"$1\" > \"$1\".nocr\n>\n> will not work on a text mounted systems because the \\r will be\n> reintroduced on writing. However scripts such as\n>\n> #!/bin/sh\n> # Remove \\r from the file given as argument\n> tr -d '\\r' | gzip | gunzip > \"$1\".nocr\n>\n> work fine. In the first case (assuming the pipes are binary) we \n> rely\n> on gunzip to set its output to binary mode, possibly overriding \n> the\n> mode used by the shell.\n>\n> was all it took to convince me this was probably a fool's errand.\n\nYeah, it looks quite crazy. I started to search for an\noption that would force the shell to provide redirection\nin binary mode, overriding the standard rules. I found\nthe igncr option [1], which is not what I need. But\napparently there have been some efforts to deal with\nline endings in bash beyond the cygwin standard rules.\nMaybe there's a useful option that I haven't found yet.\n\n[1] http://cygwin.com/ml/cygwin-announce/2007-01/msg00015.html\n\n\n> I wound up fixing our software so it would build on a binary mount,\n> which I decided was a much more sane solution.\n\nWell, our software already builds and I was not even aware\nthat there is a problem with git on cygwin until I asked\nmore people to test it. I naively chose the default option\nbecause I didn't have a reason to do otherwise. But\napparently there is an option, and people use this option.\n\nMy fear is that the first impression of git is too bad on\nWindows if it can't handle textmode. I can't recommend it.\nPeople will make me responsible for recommending them a\ntool that only cause troubles or forces them to reconfigure\ntheir cygwin, which worked for them for years. I even\nremember that we had a policy to explicitly set cygwin\nto textmode to avoid problems with cvs commits in combination\nwith Visual Studio 6.\n\n\tSteffen\n"},{"id":"50174","messageId":"46B976E5.6090508@gmail.com","threadId":"9422","inReplyTo":"7vir7r56cs.fsf@assigned-by-dhcp.cox.net","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2007-08-08T07:55:17Z","receivedAt":"2007-08-08T07:55:17Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"> Hopefully fopen() would not barf upon seeing \"b\", and O_BINARY\n> can be ifdefed to 0 on platforms where it is not applicable and\n> or'ed in to the flags. As long as they can be proven to be\n> useful on Cygwin, I do not see an issue.\n\nAccording to\n\nhttp://www.cygwin.com/faq/faq.api.html#faq.api.cr-lf\n\nadding those flags should be okay:\n\n\"Note that because the open/fopen switches are defined by ANSI, they \nexist under most flavors of Unix; open/fopen will just ignore the switch \nsince they have no meaning to UNIX.\"\n\n-- \nSebastian Schuberth\n"},{"id":"50191","messageId":"30e4a070708080650j5de7ee92p4acd7e82de7d9dff@mail.gmail.com","threadId":"9422","inReplyTo":"07BB2580-4406-496F-8ACE-F6A03D1687BE@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-08T13:50:14Z","receivedAt":"2007-08-08T13:50:14Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 8/7/07, Steffen Prohaska wrote:\n>\n> I read your message and I just checked the most recent installer\n> of cygwin (screenshot attached).\n>\n> I see three choices I'm offered:\n> 1) the path to install;\n> 2) install for all or just me;\n> 3) choose the default text file type.\n>\n> I wouldn't call that deprecated, not even obsolenscent.\n\nCall it passively deprecated. there has been a lot of discussion about\nremoving it, or at least hiding it behind the mount command and not\noffering it at all during installation. The objective of text mounts\nwas noble, but it really is hard to automatically convert any\noccurrence of crlf->lf and lf->crlf everywhere it should be done but\nnot where it should not be done. However, a lot of people use text\nmounts without trouble (or at least without complaining to the lists),\nso removing the option outright was thought too likely to cause an\nuproar. So, consider that Cygwin is taking the \"let it rot, remove it\nlater\" approach. Anyone who has troubles is generally and not so\ngently encouraged to just use binary mounts. There are some known crlf\nproblems, largely with bash/sh, pipes, forks, and redirection (of\nwhich git is a heavy user so git is a prime candidate to get into\ntrouble) that are not being worked.\n\nFor instance, when working on git-bundle.sh, I got bit by crlf\nconversions corrupting packfiles sent through a pipe on a system with\npure binary mounts and CYGWIN=binmode. The cure to that bug is\n*removing* auto-crlf conversion from Cygwin.\n\nMark\n"},{"id":"50199","messageId":"A2397231-1B81-4AD4-87CB-8FF8FB9BA89C@zib.de","threadId":"9422","inReplyTo":"30e4a070708080650j5de7ee92p4acd7e82de7d9dff@mail.gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-08T15:51:23Z","receivedAt":"2007-08-08T15:51:23Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 8, 2007, at 3:50 PM, Mark Levedahl wrote:\n\n> On 8/7/07, Steffen Prohaska wrote:\n>>\n>> I read your message and I just checked the most recent installer\n>> of cygwin (screenshot attached).\n>>\n>> I see three choices I'm offered:\n>> 1) the path to install;\n>> 2) install for all or just me;\n>> 3) choose the default text file type.\n>>\n>> I wouldn't call that deprecated, not even obsolenscent.\n>\n> Call it passively deprecated. there has been a lot of discussion about\n> removing it, or at least hiding it behind the mount command and not\n> offering it at all during installation. The objective of text mounts\n> was noble, but it really is hard to automatically convert any\n> occurrence of crlf->lf and lf->crlf everywhere it should be done but\n> not where it should not be done. However, a lot of people use text\n> mounts without trouble (or at least without complaining to the lists),\n> so removing the option outright was thought too likely to cause an\n> uproar.\n\nThat is what I'm facing now. A policy I need to handle tells\npeople explicitly to choose textmode to force cvs in cygwin to\ndo the right thing: converting lf->crlf->lf.\n\nI'm not in a position to tell them not to follow this policy;\nand I don't think it's reasonable to change the policy right away.\nThey have a lot of cvs working copies checked out and if they\nswitched from textmode to binmode now, they'd get crlf's on the\nnext commit, which they deliberately chose to avoid by using\ntextmode.\n\n\n> So, consider that Cygwin is taking the \"let it rot, remove it\n> later\" approach.\n\nThis may take years.\n\nFor me it would be easier if Cygwin (not I) told the world\nvery clearly: You must no longer use binary mounts. Consider\nswitching now, but you must switch until end of 2007. This\nwould make my life much more easier. I could tell that it's\nnot my fault and not git's fault, it's Cygwins decision to\ndrop support for textmode.\n\nPeople might complain but I think they would understand.\nProviding an option and letting people install software that is\nnot able to handle this option causes nothing but trouble. The\nvery least would be to only allow installing software that is\nknown to handle textmode. Or provide another mode that\nguarantees that no conversion takes place and offers a larger\nselection of packages.\n\n\n> Anyone who has troubles is generally and not so\n> gently encouraged to just use binary mounts. There are some known crlf\n> problems, largely with bash/sh, pipes, forks, and redirection (of\n> which git is a heavy user so git is a prime candidate to get into\n> trouble) that are not being worked.\n>\n> For instance, when working on git-bundle.sh, I got bit by crlf\n> conversions corrupting packfiles sent through a pipe on a system with\n> pure binary mounts and CYGWIN=binmode. The cure to that bug is\n> *removing* auto-crlf conversion from Cygwin.\n\nTechnically I agree. The problem is, textmode is not removed,\nbut appears as if it was supported (see installer).\n\nI'm running out of options: git in cygwin appeared to work for\nme, but it's not working in the context of the organization that\nI need to deal with. I can't force them to switch to binary mode.\nOther approaches to git on Windows are on their way, but, to my\nunderstanding, are not mature enough. git-cvsserver doesn't provide\nsufficient cvs functionality to be compatible with the needed\nworkflows.\n\nThe bottom line for me is, git does not yet support Windows in a\nusable way for the organizations that I need to convince.\n\n\tSteffen\n"},{"id":"50202","messageId":"30e4a070708080941j49b3d58cxc39bbe65f2fee9d5@mail.gmail.com","threadId":"9422","inReplyTo":"A2397231-1B81-4AD4-87CB-8FF8FB9BA89C@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-08T16:41:28Z","receivedAt":"2007-08-08T16:41:28Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 8/8/07, Steffen Prohaska wrote:\n>\n> The bottom line for me is, git does not yet support Windows in a\n> usable way for the organizations that I need to convince.\n>\n> Steffen\n>\n\nHave you considered jumping in to help on the msys git port Johannes\nSchindelin is working? He has very generously offered to do\nessentially everything except find bugs, the latter because he does\nnot actually use Windows so can't, and is clearly putting a great deal\nof effort into this. A stable and complete Windows port may be much\ncloser than you think.\n\nMark\n"},{"id":"50204","messageId":"Pine.LNX.4.64.0708081810130.14781@racer.site","threadId":"9422","inReplyTo":"30e4a070708080941j49b3d58cxc39bbe65f2fee9d5@mail.gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-08T17:20:02Z","receivedAt":"2007-08-08T17:20:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 8 Aug 2007, Mark Levedahl wrote:\n\n> On 8/8/07, Steffen Prohaska wrote:\n> >\n> > The bottom line for me is, git does not yet support Windows in a\n> > usable way for the organizations that I need to convince.\n> >\n> > Steffen\n> >\n> \n> Have you considered jumping in to help on the msys git port Johannes\n> Schindelin is working? He has very generously offered to do\n> essentially everything except find bugs, the latter because he does\n> not actually use Windows so can't, and is clearly putting a great deal\n> of effort into this. A stable and complete Windows port may be much\n> closer than you think.\n\nTo be fair, we are already a team of five working on it. The 3rd \ngeneration of the net installer works as flawlessly as the first, but \nmsysgit.git is a superproject now, containing the complete build \nenvironment you need, and has git/mingw/4msysgit.git as a submodule (yes, \nthat is a fork of a fork; they work now on repo.or.cz).\n\nPlease find it on\n\n\thttp://msysgit.googlecode.com/\n\n(It's a meager 1.4 MB, so the whole rest is git-cloned natively!) It \nalready passes all tests, is able to start gitk and git-gui, and more is \nto come!\n\nAnd no, I did not agree to do _everything_. I agreed to do things _when I \nget something in return_.\n\nFor example, we have a functional script sitting in msysgit.git which \nbuilds a complete WinGit installer (WinGit being the code name for \"Git on \nMSys without the whole build environment\").\n\nIt is incomplete in only a few issues:\n\n\t- it does not install anything in the start menu\n\n\t- it does not install any short cut on the Desktop\n\n\t- it does not install anything in the Quick Launch bar\n\n\t- it does not include a nice WelcomeToGit.html, to be launched \n\t after a successful install\n\n\t- it does not contain a nice way to start git-gui (you have to \n\t start it by hand from the command line inside bash)\n\n\t- etc.\n\nSo go for it, everybody, or alternatively do not even bother to whine.\n\nCiao,\nDscho\n\nP.S.: I'll be not really available for a few days, starting from tomorrow, \nso do use the mailing list to keep in touch with others working on msysgit \nor 4msysgit, and do use the mob branch (you can bug the project members \nlisted on the homepage to cherry-pick, sign off and push if need be).\n"},{"id":"50217","messageId":"75EB313E-807D-44FB-A186-A151F182B47B@zib.de","threadId":"9422","inReplyTo":"Pine.LNX.4.64.0708081810130.14781@racer.site","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-08T19:37:50Z","receivedAt":"2007-08-08T19:37:50Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:\n\n> On Wed, 8 Aug 2007, Mark Levedahl wrote:\n>\n>> On 8/8/07, Steffen Prohaska wrote:\n>>>\n>>> The bottom line for me is, git does not yet support Windows in a\n>>> usable way for the organizations that I need to convince.\n>>>\n>>> Steffen\n>>>\n>>\n>> Have you considered jumping in to help on the msys git port Johannes\n>> Schindelin is working? He has very generously offered to do\n>> essentially everything except find bugs, the latter because he does\n>> not actually use Windows so can't, and is clearly putting a great \n>> deal\n>> of effort into this. A stable and complete Windows port may be much\n>> closer than you think.\n>\n\nI'll look into it. However, my situation is similar to Johannes'. I do\nnot regularly work on Windows. I use my Mac for all office work and\ntypically code on Linux. However, I do use Windows from time to time\nbecause the majority of the people I work with use Windows.\n\nI have a real Windows running in a Virtual Machine and I consider\nswitching to it for a while, to see if things run smoothly. Here is\nwhat I plan to do: I will set cygwin to textmode (!), although I know\nbetter. But this is what most of the people I work with have. I'll\nuninstall cygwin's git and install msysgit instead. I'll try to do\nall the integration work, that is import from cvs on Linux, pull to\nWindows and do coding and merges on Windows. I'll push back to Linux\nand Mac for testing.\n\nAfter the basic stuff, like pull, push, merge, commit, gitk, and\ngit gui, here's my first more difficult task: Will git-mergetool\nlaunch something useful for me on Windows? I heard that WinDiff\nwould be useful. On Mac I use FileMerge.\n\n> To be fair, we are already a team of five working on it. The 3rd\n> generation of the net installer works as flawlessly as the first, but\n> msysgit.git is a superproject now, containing the complete build\n> environment you need, and has git/mingw/4msysgit.git as a submodule \n> (yes,\n> that is a fork of a fork; they work now on repo.or.cz).\n>\n> Please find it on\n>\n> \thttp://msysgit.googlecode.com/\n>\n> (It's a meager 1.4 MB, so the whole rest is git-cloned natively!) It\n> already passes all tests, is able to start gitk and git-gui, and \n> more is\n> to come!\n>\n> And no, I did not agree to do _everything_. I agreed to do things \n> _when I\n> get something in return_.\n\nI read this before. At the time you wrote about this on the mailing list\nI thought that cygwin would be fine. I wasn't aware of the binmode/ \ntextmode\nmagic and all the problems caused by it.\n\n> For example, we have a functional script sitting in msysgit.git which\n> builds a complete WinGit installer (WinGit being the code name for \n> \"Git on\n> MSys without the whole build environment\").\n>\n> It is incomplete in only a few issues:\n>\n> \t- it does not install anything in the start menu\n>\n> \t- it does not install any short cut on the Desktop\n>\n> \t- it does not install anything in the Quick Launch bar\n>\n> \t- it does not include a nice WelcomeToGit.html, to be launched\n> \t after a successful install\n>\n> \t- it does not contain a nice way to start git-gui (you have to\n> \t start it by hand from the command line inside bash)\n>\n> \t- etc.\n>\n> So go for it, everybody, or alternatively do not even bother to whine.\n\nI don't care about these things. I typically start the Explorer by \ntyping\nexplorer into the 'Run ...' box of the start meny. So don't expect \nanything\nfrom me that makes git more beautiful.\n\nThe only thing I want to achieve is a flawlessly running git that works\nout-of-the box in the presence of a cygwin in textmode (!). If possible\ngit should have the same version number that I have on Linux and Mac,\nwhich means the master branch of Junio's repo on my Mac. Lagging a bit\nbehind for a while is ok, but in general I'd prefer to have the same\nversion on Linux, Mac, and Windows. What I described means Windows \nsupport\nfor me. Having a nice installer is not important.\n\n> Ciao,\n> Dscho\n>\n> P.S.: I'll be not really available for a few days, starting from \n> tomorrow,\n> so do use the mailing list to keep in touch with others working on \n> msysgit\n> or 4msysgit, and do use the mob branch (you can bug the project \n> members\n> listed on the homepage to cherry-pick, sign off and push if need be).\n>\n\nok. I'll be available for one more week and will then be offline\nfor three weeks.\n\n\tSteffen\n"},{"id":"50226","messageId":"2F00D32E-8D0C-48D6-86E1-6F6E7611E364@zib.de","threadId":"9422","inReplyTo":"75EB313E-807D-44FB-A186-A151F182B47B@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-08T20:13:25Z","receivedAt":"2007-08-08T20:13:25Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 8, 2007, at 9:37 PM, Steffen Prohaska wrote:\n\n> I have a real Windows running in a Virtual Machine and I consider\n> switching to it for a while, to see if things run smoothly. Here is\n> what I plan to do: I will set cygwin to textmode (!), although I know\n> better. But this is what most of the people I work with have. I'll\n> uninstall cygwin's git and install msysgit instead. I'll try to do\n> all the integration work, that is import from cvs on Linux, pull to\n> Windows and do coding and merges on Windows. I'll push back to Linux\n> and Mac for testing.\n\nHere we go... I tried GitMe-3.exe.\n\nI have two 'crashes' during installation. I attached snapshots\nof the requesters. I don't know how to copy text from the\ninstaller. Therefore I attached snapshots.\n\nAs mentioned before, I run in a virtual machine, Parallels to be exact.\nI use my Windows installation rarely but I did not have any problems\nwith Windows in Parallels before.\n\n\tSteffen\n\n\n \n \n\n\n"},{"id":"50230","messageId":"7E22DF40-1E28-4B8A-B132-18B05136B5E9@zib.de","threadId":"9422","inReplyTo":"2F00D32E-8D0C-48D6-86E1-6F6E7611E364@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-08T20:36:59Z","receivedAt":"2007-08-08T20:36:59Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 8, 2007, at 10:13 PM, Steffen Prohaska wrote:\n\n> I have two 'crashes' during installation. I attached snapshots\n> of the requesters. I don't know how to copy text from the\n> installer. Therefore I attached snapshots.\n\nHmm... how do I get started? I naively chose cygwin as my\nshell. I set\n\nexport PATH=$PATH:/cygdrive/c/msysgit/bin\n\nthen I tried\n\n$ git clone git://git.kernel.org/pub/scm/git/git.git\nc:/msysgit/bin/git-clone: line 214: git-init: command not found\n\nMaybe it's related to the errors during installation?\n\nHow can I build and install git manually, based on the result\nof GitMe-3's basic setup?\n\n\tSteffen\n"},{"id":"50243","messageId":"Pine.LNX.4.64.0708082228520.21857@racer.site","threadId":"9422","inReplyTo":"75EB313E-807D-44FB-A186-A151F182B47B@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-08T21:30:04Z","receivedAt":"2007-08-08T21:30:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 8 Aug 2007, Steffen Prohaska wrote:\n\n> On Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:\n> \n> > So go for it, everybody, or alternatively do not even bother to whine.\n> \n> I don't care about these things. I typically start the Explorer by \n> typing explorer into the 'Run ...' box of the start meny. So don't \n> expect anything from me that makes git more beautiful.\n\nThat's nice to hear. Finally somebody honest. I'll return the favour: I \nhave no time to work on the bugs you sent in a reply.\n\nCiao,\nDscho\n"},{"id":"50264","messageId":"46BA4C98.4050005@gmail.com","threadId":"9422","inReplyTo":"7E22DF40-1E28-4B8A-B132-18B05136B5E9@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-08T23:07:04Z","receivedAt":"2007-08-08T23:07:04Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Steffen Prohaska wrote:\n>\nLet me guess, you have Cygwin on the path along with Msys, and had it \nthat way when you downloaded the package and it tried to build. Hmmm. \nMaybe Cygwin executables conflict with Msys executables. Nah. Couldn't \nbe. Must be a bug.\n\nMark\n"},{"id":"50277","messageId":"D6212E0B-0CCB-4F55-A19C-24734BAA90C7@zib.de","threadId":"9422","inReplyTo":"46BA4C98.4050005@gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-09T04:59:23Z","receivedAt":"2007-08-09T04:59:23Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 9, 2007, at 1:07 AM, Mark Levedahl wrote:\n\n> Steffen Prohaska wrote:\n>>\n> Let me guess, you have Cygwin on the path along with Msys, and had \n> it that way when you downloaded the package and it tried to build.\n\nI don't think so. At least I did not actively do something to\nhave Cygwin in my path.\n\n\tSteffen\n"},{"id":"50282","messageId":"46BAADC8.9020003@trolltech.com","threadId":"9422","inReplyTo":"7E22DF40-1E28-4B8A-B132-18B05136B5E9@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-08-09T06:01:44Z","receivedAt":"2007-08-09T06:01:44Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":">> I have two 'crashes' during installation. I attached snapshots of\n>> the requesters. I don't know how to copy text from the installer.\n>> Therefore I attached snapshots.\n> \n> Hmm... how do I get started? I naively chose cygwin as my shell. I\n> set\n> \n> export PATH=$PATH:/cygdrive/c/msysgit/bin\n> \n> then I tried\n> \n> $ git clone git://git.kernel.org/pub/scm/git/git.git \n> c:/msysgit/bin/git-clone: line 214: git-init: command not found\n> \n> Maybe it's related to the errors during installation?\n> \n> How can I build and install git manually, based on the result of\n> GitMe-3's basic setup?\n\nOk, first, which system is this? Windows 2000/XP/Vista?\n(The Gitme installer doesn't work on old ones for now)\n\nTry running gitme from a terminal. Download gitme-3.exe into C:\\temp, \nopen a native terminal (Start - Run - Type \"cmd\" ); then in the \nterminal, type:\n C:\\temp> set PATH=%WINDIR%\\system32;%WINDIR%\n C:\\temp> gitme-3\n\nDoes it work then? If so, the problem is likely to be that you have \nCygwin in the system path, which is not advisable/compatible with MSys.\n\n-- \n.marius\n\n"},{"id":"50283","messageId":"76795DDC-29A5-4C7E-B56E-A6316A183C75@zib.de","threadId":"9422","inReplyTo":"Pine.LNX.4.64.0708082228520.21857@racer.site","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-09T06:20:54Z","receivedAt":"2007-08-09T06:20:54Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 8, 2007, at 11:30 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Wed, 8 Aug 2007, Steffen Prohaska wrote:\n>\n>> On Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:\n>>\n>>> So go for it, everybody, or alternatively do not even bother to \n>>> whine.\n>>\n>> I don't care about these things. I typically start the Explorer by\n>> typing explorer into the 'Run ...' box of the start meny. So don't\n>> expect anything from me that makes git more beautiful.\n>\n> That's nice to hear. Finally somebody honest. I'll return the \n> favour: I\n> have no time to work on the bugs you sent in a reply.\n\nThat's fine. I don't expect anything, except for being honest about\nthe level of Windows support that is currently available. In retrospect,\nI relied on the claim that git works in Cygwin without problems (not\nmade by you but on the mailing list in general). This claim turns out\nto be wrong for me, because it highly depends on the details of how you\nconfigure your Cygwin, which makes it impossible to run git in Cygwin\nthat is configured according to the 'wrong' policy.\n\nAny hint how I can start debugging? I saw mingw for the\nfirst time in my life, yesterday. I only worked with cygwin and various\nVisual Studio versions, before.\n\n[ btw, my point was that I'm mostly interested in getting the basic\nstuff going first. That is git with the same functionality that\nI have on Linux and Mac. The next would be a good integration with\nuseful tools on Windows, for example git-mergetool should launch\nWindows three-way merge tools. The thing I'm least interested is\na beautiful installer, which clutters my Desktop with icons, which\nI never use and need to cleanup later anyway.\n\nBottom line: if you have points on your list that better fit the\ndescribed priorities, there would be a good chance that I can look\ninto one or two of them, for example\n\nIs anything needed to get mingw changes merged to the official repo?\nIs anything needed to get changes from the official repo to mingw?\n\nMy goal would be to type 'make windist' in the official repo and\nget a very basic installer (maybe just a zip archive) that contains\neverything needed to run git on Windows. Unpacking this self-contained\ninstaller on a freshly installed Windows should get you going. There\nshould be no need to install Cygwin or something else.\n\nIs this realistic?\nWhat is needed to get there?\nWhat would be an estimated timeframe to achieve this goal?\n\nWill all this run on Windows XP 64 bit and Windows Vista 64 bit?\n\nAfter I'm convinced that the level of support for Windows is\nsufficient, I will recommend using it, which means that approximately\n30 developers will start using git in the way I describe to them.\nThis will generate a lot of real-world testing. But it should not\ngenerate too many critical issues. People will blame me for\nrecommending them the tool. ]\n\n\nBack to debugging...\n\nI tried the following (is this the right way to go?)\n\n- double click on c:\\msysgit\\msys.bat to start a shell.\n- cd git\n- make\ncompiles with some warnings ..., and crashed with a popup...\nThe popup says (translated to english):\n\"NTVDM-CPU detected an invalid instruction.\nCS:0000 IP:0077 OP: f0 37 05 0c 02 click to close the application.\"\n\nthe last lines I see in the shell are\n\nLINK test-match-trees.exe\nSUBDIR git-gui\nINDEX lib/\n\nI clicked and the compilation stops. My shell remains alive.\nSo, I started to run tests.\n\nt0000-basic fails on creation of symlinks. Apparently mingw\ndoesn't support symlinks to files that do not exist. I reports\n'ln: creating symbolic link 'path0sym' to 'hello path0' fails'.\n\nI tried with 'export no_symlinks=1' (is this the right thing\nto do? Who should set no_symlinks=1? Should it be set by the\nmakefile or in some global architecture configuration?).\n\nNow t0000-basic runs except for some noise created by failing\nln, which is not detected as a failure by the test script.\n\nso I ran all tests and they look good. Only t7004\nreported 'gpg: error loading iconv.dll'.\n\nI tried 'make install' which yields another crash popup.\nThen I tried 'make -k install'\n\nWow... this crashed my virtual machine. Maybe Parallels should\nadd msysgit to their test cases. If I read their automatically\ngenerated bugreport correctly it's again related to an invalid\ninstruction. Maybe mingw uses some op codes it shouldn't?\n\nHmm... I planned to upgrade to the newest release of Parallels\nanyway. Hopefully it's more stable in this regards.\n\nI set NO_TCLTK=1 in the Makefile to skip git-gui during installation.\nThe installation finished without reporting any problem. Maybe\nI have a working git now ...\n\n\tSteffen\n"},{"id":"50284","messageId":"872D90BF-CB37-496B-9E7D-3C9A19125EBA@zib.de","threadId":"9422","inReplyTo":"46BAADC8.9020003@trolltech.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-09T06:38:33Z","receivedAt":"2007-08-09T06:38:33Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 9, 2007, at 8:01 AM, Marius Storm-Olsen wrote:\n\n>>> I have two 'crashes' during installation. I attached snapshots of\n>>> the requesters. I don't know how to copy text from the installer.\n>>> Therefore I attached snapshots.\n>> Hmm... how do I get started? I naively chose cygwin as my shell. I\n>> set\n>> export PATH=$PATH:/cygdrive/c/msysgit/bin\n>> then I tried\n>> $ git clone git://git.kernel.org/pub/scm/git/git.git c:/msysgit/ \n>> bin/git-clone: line 214: git-init: command not found\n>> Maybe it's related to the errors during installation?\n>> How can I build and install git manually, based on the result of\n>> GitMe-3's basic setup?\n>\n> Ok, first, which system is this? Windows 2000/XP/Vista?\n> (The Gitme installer doesn't work on old ones for now)\n\nXP 32bit.\n\n> Try running gitme from a terminal. Download gitme-3.exe into C: \n> \\temp, open a native terminal (Start - Run - Type \"cmd\" ); \n> then in the terminal, type:\n> C:\\temp> set PATH=%WINDIR%\\system32;%WINDIR%\n> C:\\temp> gitme-3\n\n> Does it work then? If so, the problem is likely to be that you have \n> Cygwin in the system path, which is not advisable/compatible with \n> MSys.\n\nI had cygwin at the tail of my PATH. After removing it the\ninstallation went through flawlessly.\n\nA check in the installer would be a good idea.\n\nWould you recommend running git only from the mingw shell prompt,\nor can I start it also from a Cygwin shell prompt?\n\nThanks a lot,\n\n\tSteffen\n"},{"id":"50288","messageId":"46BAB86B.8070904@trolltech.com","threadId":"9422","inReplyTo":"872D90BF-CB37-496B-9E7D-3C9A19125EBA@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-08-09T06:47:07Z","receivedAt":"2007-08-09T06:47:07Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Steffen Prohaska said the following on 09.08.2007 08:38:\n> On Aug 9, 2007, at 8:01 AM, Marius Storm-Olsen wrote:\n>> Does it work then? If so, the problem is likely to be that you\n>> have Cygwin in the system path, which is not advisable/compatible\n>> with MSys.\n> \n> I had cygwin at the tail of my PATH. After removing it the \n> installation went through flawlessly.\n> \n> A check in the installer would be a good idea.\n> \n> Would you recommend running git only from the mingw shell prompt, \n> or can I start it also from a Cygwin shell prompt?\n\nWell, some say that you can, but I'm not sure (especially since you're \nusing Cygwin in Windows EOL mode, which is opposite of MSys).\nThe way I use it is either from the MSys shell, or directly from CMD \nshell. (If you have PATH=c:\\msysgit\\bin;C:\\msysgit\\mingw\\bin;%PATH% it \nworks quite well like that.)\n\nActually, I use CMD most of the time..\n\n-- \n.marius\n\n"},{"id":"50301","messageId":"Pine.LNX.4.64.0708090949200.21857@racer.site","threadId":"9422","inReplyTo":"46BAADC8.9020003@trolltech.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-09T08:50:14Z","receivedAt":"2007-08-09T08:50:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 9 Aug 2007, Marius Storm-Olsen wrote:\n\n> Try running gitme from a terminal.\n\nAnd there I thought that you download GitMe-3.exe, and then double click \non it...\n\nCiao,\nDscho\n"},{"id":"50304","messageId":"46BAD793.9040906@trolltech.com","threadId":"9422","inReplyTo":"Pine.LNX.4.64.0708090949200.21857@racer.site","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-08-09T09:00:03Z","receivedAt":"2007-08-09T09:00:03Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin said the following on 09.08.2007 10:50:\n> On Thu, 9 Aug 2007, Marius Storm-Olsen wrote:\n>> Try running gitme from a terminal.\n> And there I thought that you download GitMe-3.exe, and then double\n> click on it...\n\nHeh, yeah, normally that's indeed what you do. However, in this case I \nasked him to start it from the terminal to make sure that it wasn't \naffected by anything suspicious in his system PATH.\n\nClearly having Cygwin in his path messed things up.\n\n-- \n.marius\n\n"},{"id":"50312","messageId":"DFEB6116-ABB4-4D61-92E4-0688604069DE@zib.de","threadId":"9422","inReplyTo":"46BAD793.9040906@trolltech.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-09T10:33:35Z","receivedAt":"2007-08-09T10:33:35Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 9, 2007, at 11:00 AM, Marius Storm-Olsen wrote:\n\n> Johannes Schindelin said the following on 09.08.2007 10:50:\n>> On Thu, 9 Aug 2007, Marius Storm-Olsen wrote:\n>>> Try running gitme from a terminal.\n>> And there I thought that you download GitMe-3.exe, and then double\n>> click on it...\n>\n> Heh, yeah, normally that's indeed what you do. However, in this \n> case I asked him to start it from the terminal to make sure that it \n> wasn't affected by anything suspicious in his system PATH.\n>\n> Clearly having Cygwin in his path messed things up.\n\nI think checking for a proper setup in the installer would\nbe a good idea, like checking if 'cygpath' runs and if so,\ndie with the request to cleanup the system PATH first.\n\nThe problem was not too hard to solve, but the first\nimpression was not optimal.\n\nWhere would I have to look to add something like this?\n\n\tSteffen\n"},{"id":"50379","messageId":"e7bda7770708092307g49fa9976l5f9972592129fc8e@mail.gmail.com","threadId":"9422","inReplyTo":"76795DDC-29A5-4C7E-B56E-A6316A183C75@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Torgil Svensson","fromEmail":"torgil.svensson@gmail.com","sentAt":"2007-08-10T06:07:03Z","receivedAt":"2007-08-10T06:07:03Z","isPatch":false,"sender":{"key":"torgil.svensson@gmail.com","avatar":null},"body":"On 8/9/07, Steffen Prohaska wrote:\n\n> The next would be a good integration with\n> useful tools on Windows, for example git-mergetool should launch\n> Windows three-way merge tools.\n\nDo you mean tools included in Windows or tools using the Windows API?\n\n\n> My goal would be to type 'make windist' in the official repo and\n> get a very basic installer (maybe just a zip archive) that contains\n> everything needed to run git on Windows. Unpacking this self-contained\n> installer on a freshly installed Windows should get you going. There\n> should be no need to install Cygwin or something else.\n>\n> Is this realistic?\n> What is needed to get there?\n> What would be an estimated timeframe to achieve this goal?\n>\n> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?\n\nHow fast can you type?\n\nWhy does it have to be the _official_ repo? Git have submodule\nsupport, so you could do a repo called\n\"my_excellent_git_environment_for_windows.git\" and have the official\nrepo as submodule (msysgit is done this way).\n\nYou could even start with cloning the TortoiseSVN repo using git. Or\nmaybe even better, since KDE4 will compile on Windows [take on wood],\ndo it as a kioslave (or whatever mechanism) to have an environment\nthat works in both Windows and Linux and most OtherOs:es. Aiming for\nenvironments that works on several OSes is a good thing for future\nmigrations.\n\n//Torgil\n"},{"id":"50383","messageId":"2383328F-300E-459C-A299-90242DA230F7@zib.de","threadId":"9422","inReplyTo":"e7bda7770708092307g49fa9976l5f9972592129fc8e@mail.gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-10T07:19:41Z","receivedAt":"2007-08-10T07:19:41Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:\n\n> On 8/9/07, Steffen Prohaska wrote:\n>\n>> The next would be a good integration with\n>> useful tools on Windows, for example git-mergetool should launch\n>> Windows three-way merge tools.\n>\n> Do you mean tools included in Windows or tools using the Windows API?\n\nI think both. I'm currently conducting a survey what the Windows\nusers I'm working with are using. Up to now I have no idea what these\ntools do. Note, I'm not working on Windows. But I would like to see\ngit starting the tools that users prefer to use.\n\nGit would just feel more like a useful Windows tool if it interacted\nwith other useful Windows tools.\n\nHere is what I have on my list (not yet prioritized):\n\n- WinMerge (http://winmerge.org/)\n\n- Visual Comparer (http://www.nikeware.com/vc-features.htm)\n\n- Araxis Merge, http://www.araxis.com/merge/ (expensive!)\n\n- Beyond Compare, http://www.scootersoftware.com/file-comparison.php \n(will support 3-way with upcoming version 3; reasonable price)\n\n- KDiff3, http://kdiff3.sourceforge.net/ (comes with Windows- \ninstaller from SF)\n\n- ECMerge, http://www.elliecomputing.com/Products/merge_overview.asp \n(OSS developer can get a \"Pro\" license for free upon request)\n\nA complete list at\nhttp://en.wikipedia.org/wiki/Comparison_of_file_comparison_tools\n\n\n>\n>> My goal would be to type 'make windist' in the official repo and\n>> get a very basic installer (maybe just a zip archive) that contains\n>> everything needed to run git on Windows. Unpacking this self- \n>> contained\n>> installer on a freshly installed Windows should get you going. There\n>> should be no need to install Cygwin or something else.\n>>\n>> Is this realistic?\n>> What is needed to get there?\n>> What would be an estimated timeframe to achieve this goal?\n>>\n>> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?\n>\n> How fast can you type?\n\nI don't see your point. The question is if git runs flawlessly\non 64 bit systems, which we use for development. I have no experience\nwith mingw. Maybe there are some issues with 64 bit Windows, maybe\nnot. But its a reasonable question?\n\n\n> Why does it have to be the _official_ repo? Git have submodule\n> support, so you could do a repo called\n> \"my_excellent_git_environment_for_windows.git\" and have the official\n> repo as submodule (msysgit is done this way).\n\nThe official repo would indicate a real commitment to me that\nWindows support if officially maintained.\n\nI agree that there may be more tools group around core git. But\ncore git itself should be the master from the official repo.\nThis seems to be a reasonable goal to me. At least that is what\nwe do. The head must compile on all supported platforms\nout-of-the-box.\n\n\n> You could even start with cloning the TortoiseSVN repo using git. Or\n> maybe even better, since KDE4 will compile on Windows [take on wood],\n> do it as a kioslave (or whatever mechanism) to have an environment\n> that works in both Windows and Linux and most OtherOs:es. Aiming for\n> environments that works on several OSes is a good thing for future\n> migrations.\n\nI work for years now on cross platform code. I never needed a whole\nenvironment. I need Qt and the native development environment, like\nVisual Studio, gcc, Xcode. I don't need KDE on Windows, I don't need\nKDE on Mac. Everything's there already.\n\n\tSteffen\n"},{"id":"50398","messageId":"Pine.LNX.4.64.0708101121240.21857@racer.site","threadId":"9422","inReplyTo":"2383328F-300E-459C-A299-90242DA230F7@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-10T10:30:30Z","receivedAt":"2007-08-10T10:30:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 10 Aug 2007, Steffen Prohaska wrote:\n\n> On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:\n> \n> > On 8/9/07, Steffen Prohaska wrote:\n> > \n> > > Will all this run on Windows XP 64 bit and Windows Vista 64 bit?\n> > \n> > How fast can you type?\n> \n> I don't see your point. The question is if git runs flawlessly\n> on 64 bit systems, which we use for development. I have no experience\n> with mingw. Maybe there are some issues with 64 bit Windows, maybe\n> not. But its a reasonable question?\n\nIt would be, if\n\n- more people had 64-bit platforms to run on, and\n- more people had Windows 64-bit.\n\nBoth cost money, so I suggest just trying it for yourself if you are one \nof the few lucky ones being actually _able_ to test.\n\nAnd no, I will not buy a Windows 64-bit just to test it for you.\n\n> > Why does it have to be the _official_ repo? Git have submodule\n> > support, so you could do a repo called\n> > \"my_excellent_git_environment_for_windows.git\" and have the official\n> > repo as submodule (msysgit is done this way).\n> \n> The official repo would indicate a real commitment to me that\n> Windows support if officially maintained.\n\nI cannot speak for others, of course, but this is a freeloader mentality I \ndo not want to support.\n\nIf you want first class Windows support, you'll have to pay for that, \nmethinks. And seeing all those less-than-even-lousy SCMs getting major \nfinancial contributions to support their mediocrity, I do not see a reason \nto get small amounts from private people, but rather substantial \nmoney-flow from big companies.\n\nGit is an excellent tool. If people want it badly enough, they should do \nsomething for it.\n\n> I agree that there may be more tools group around core git. But\n> core git itself should be the master from the official repo.\n> This seems to be a reasonable goal to me. At least that is what\n> we do. The head must compile on all supported platforms\n> out-of-the-box.\n\nGuess why mingw.git is called a \"fork\"? It is _not good enough_ yet to be \nincluded. Not necessarily function-wise, but definitely code-wise. We \nhave quite strict coding rules, being an Open Source project where \neverybody can see your mess, should there be one.\n\nIt has _never_ been the plan to maintain mingw.git independently for \neternity. But the progress has been slow, and the _only_ reason that \nthere was any progress _at all_ was that Hannes stepped up, and did some \nactual work instead of talking.\n\nSo yes, mingw.git's target destination is git.git.\n\nCiao,\nDscho\n"},{"id":"50400","messageId":"66F583A1-0F11-4917-B674-C38F7C2E31B8@zib.de","threadId":"9422","inReplyTo":"Pine.LNX.4.64.0708101121240.21857@racer.site","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-10T11:14:20Z","receivedAt":"2007-08-10T11:14:20Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 10, 2007, at 12:30 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Fri, 10 Aug 2007, Steffen Prohaska wrote:\n>\n>> On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:\n>>\n>>> On 8/9/07, Steffen Prohaska wrote:\n>>>\n>>>> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?\n>>>\n>>> How fast can you type?\n>>\n>> I don't see your point. The question is if git runs flawlessly\n>> on 64 bit systems, which we use for development. I have no experience\n>> with mingw. Maybe there are some issues with 64 bit Windows, maybe\n>> not. But its a reasonable question?\n>\n> It would be, if\n>\n> - more people had 64-bit platforms to run on, and\n> - more people had Windows 64-bit.\n>\n> Both cost money, so I suggest just trying it for yourself if you \n> are one\n> of the few lucky ones being actually _able_ to test.\n>\n> And no, I will not buy a Windows 64-bit just to test it for you.\n\nI'll try. I only asked if there is any experience on this. I didn't\nask you to test it for me.\n\n\n>>> Why does it have to be the _official_ repo? Git have submodule\n>>> support, so you could do a repo called\n>>> \"my_excellent_git_environment_for_windows.git\" and have the official\n>>> repo as submodule (msysgit is done this way).\n>>\n>> The official repo would indicate a real commitment to me that\n>> Windows support if officially maintained.\n>\n> I cannot speak for others, of course, but this is a freeloader \n> mentality I\n> do not want to support.\n>\n> If you want first class Windows support, you'll have to pay for that,\n> methinks. And seeing all those less-than-even-lousy SCMs getting \n> major\n> financial contributions to support their mediocrity, I do not see a \n> reason\n> to get small amounts from private people, but rather substantial\n> money-flow from big companies.\n>\n> Git is an excellent tool. If people want it badly enough, they \n> should do\n> something for it.\n\nYou may have noticed that I'm willing to put some time into\nit. I can't offer money. Time should be fine, too as you\nstate on msysgit's homepage\n\n\"Testing and reporting bugs is really already a big help.\nOf course, it is even better if you get involved, for example\nby hacking on mingw.git.\"\n\nThat is what I'm doing. You get bug reports and you get\npatches. I don't understand your point about freeloader\nmentality. In the long run it's just easier to keep functionality\nin sync if it is maintained in a single repo, and this is what\nyou're basically also saying below.\n\n\n>> I agree that there may be more tools group around core git. But\n>> core git itself should be the master from the official repo.\n>> This seems to be a reasonable goal to me. At least that is what\n>> we do. The head must compile on all supported platforms\n>> out-of-the-box.\n>\n> Guess why mingw.git is called a \"fork\"? It is _not good enough_ \n> yet to be\n> included. Not necessarily function-wise, but definitely code- \n> wise. We\n> have quite strict coding rules, being an Open Source project where\n> everybody can see your mess, should there be one.\n\nWell and here, again, is my point of one single repo that officially\nsupports Windows. If the official support is part of the 'quite\nstrict coding' rules then I'm more convinced that Windows is\nsupported with appropriate quality. This is the point I want to make.\nIt has nothing to do with freeloader mentality.\n\n\n> It has _never_ been the plan to maintain mingw.git independently for\n> eternity. But the progress has been slow, and the _only_ reason that\n> there was any progress _at all_ was that Hannes stepped up, and did \n> some\n> actual work instead of talking.\n>\n> So yes, mingw.git's target destination is git.git.\n\nGood to hear. Again, I prefer to put work into pushing the merge\nwith git.git forward, than putting work into any fancy gui stuff,\nas you proposed recently.\n\nSo if there's a list of todos that hinder a merge back to git.git,\nI'd happy to learn about it.\n\n\tSteffen\n"},{"id":"50446","messageId":"e7bda7770708101531n782118e9qb9c6de4e934940ea@mail.gmail.com","threadId":"9422","inReplyTo":"2383328F-300E-459C-A299-90242DA230F7@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Torgil Svensson","fromEmail":"torgil.svensson@gmail.com","sentAt":"2007-08-10T22:31:32Z","receivedAt":"2007-08-10T22:31:32Z","isPatch":false,"sender":{"key":"torgil.svensson@gmail.com","avatar":null},"body":"On 8/10/07, Steffen Prohaska wrote:\n\n> [..list of tools and links]\n\nThank you for the information! i'll check those up.\n\n> >> My goal would be to type 'make windist' in the official repo and\n> >> get a very basic installer (maybe just a zip archive) that contains\n> >> everything needed to run git on Windows. Unpacking this self-\n> >> contained\n> >> installer on a freshly installed Windows should get you going. There\n> >> should be no need to install Cygwin or something else.\n> >>\n> >> Is this realistic?\n> >> What is needed to get there?\n> >> What would be an estimated timeframe to achieve this goal?\n> >>\n> >> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?\n> >\n> > How fast can you type?\n>\n> I don't see your point. The question is if git runs flawlessly\n> on 64 bit systems, which we use for development. I have no experience\n> with mingw. Maybe there are some issues with 64 bit Windows, maybe\n> not. But its a reasonable question?\n>\n> > Why does it have to be the _official_ repo? Git have submodule\n> > support, so you could do a repo called\n> > \"my_excellent_git_environment_for_windows.git\" and have the official\n> > repo as submodule (msysgit is done this way).\n>\n> The official repo would indicate a real commitment to me that\n> Windows support if officially maintained.\n\nI agree it's reasonable questions. My point is that to get something,\nyou have to be active (and you're a prime example of that I think).\n\nQuoted from http://git.or.cz/ : \"Traditionally, the low-level part of\nGit is called plumbing and the interfaces and frontends are called\nporcelains. Git itself comes with a default porcelain bundled and that\nis actually what you will normally mean when you say you use Git.\"\n\n\nWhat do you include in the \"make windist\" installer and the \"Windows\nsupport\" ? Are you talking porcelain or plumbing?\n\n>> Aiming for\n>> environments that works on several OSes is a good thing for future\n>> migrations.\n> I work for years now on cross platform code. I never needed a whole\n> environment. I need Qt and the native development environment, like\n> Visual Studio, gcc, Xcode. I don't need KDE on Windows, I don't need\n> KDE on Mac. Everything's there already.\n\nGood thing you're flexible and have a broad experience. Not everyone\nout there has that and it can be tricky to try to lure those people\naway from 10yrs habits.\n\n//Torgil\n"},{"id":"50453","messageId":"EF7DFA5A-9C3A-4D0B-9533-D1D60AE4A44C@zib.de","threadId":"9422","inReplyTo":"e7bda7770708101531n782118e9qb9c6de4e934940ea@mail.gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-11T00:43:54Z","receivedAt":"2007-08-11T00:43:54Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 11, 2007, at 12:31 AM, Torgil Svensson wrote:\n\n> On 8/10/07, Steffen Prohaska wrote:\n>\n>> [..list of tools and links]\n>\n> Thank you for the information! i'll check those up.\n\n\nI hope to have an improved list on monday, sorted by priority of\nthe developers I'm working with.\n\nI thought I do some coding, to find out a bit more about the\nstability of msysgit. So I started and added support for kdiff3\non Windows (see patches in separate mail).\n\nI'm impressed. Pretty much everything I tried today worked for\nme. After I got git gui running, and learned how to avoid pitfalls\nof git submodule, development went smoothly. I pushed and pulled a\nbit from linux and mac and did some coding. Thanks for the vim\nsetup!\n\nI think you (and more people I don't yet know) did a great job\nwith msysgit. I'd recommend it over cygwin's git, which caused\nsome trouble for me.\n\nThanks!\n\n>>>> My goal would be to type 'make windist' in the official repo and\n>>>> get a very basic installer (maybe just a zip archive) that contains\n>>>> everything needed to run git on Windows. Unpacking this self-\n>>>> contained\n>>>> installer on a freshly installed Windows should get you going. \n>>>> There\n>>>> should be no need to install Cygwin or something else.\n>>>>\n>>>> Is this realistic?\n>>>> What is needed to get there?\n>>>> What would be an estimated timeframe to achieve this goal?\n>>>>\n>>>> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?\n>>>\n>>> How fast can you type?\n>>\n>> I don't see your point. The question is if git runs flawlessly\n>> on 64 bit systems, which we use for development. I have no experience\n>> with mingw. Maybe there are some issues with 64 bit Windows, maybe\n>> not. But its a reasonable question?\n>>\n>>> Why does it have to be the _official_ repo? Git have submodule\n>>> support, so you could do a repo called\n>>> \"my_excellent_git_environment_for_windows.git\" and have the official\n>>> repo as submodule (msysgit is done this way).\n>>\n>> The official repo would indicate a real commitment to me that\n>> Windows support if officially maintained.\n>\n> I agree it's reasonable questions. My point is that to get something,\n> you have to be active (and you're a prime example of that I think).\n>\n> Quoted from http://git.or.cz/ : \"Traditionally, the low-level part of\n> Git is called plumbing and the interfaces and frontends are called\n> porcelains. Git itself comes with a default porcelain bundled and that\n> is actually what you will normally mean when you say you use Git.\"\n>\n>\n> What do you include in the \"make windist\" installer and the \"Windows\n> support\" ? Are you talking porcelain or plumbing?\n\nHard to say. I believe now, from what I learned today, that the msysgit\napproach is quite reasonable: Grouping all needed unix tools around a\nsubmodule containing git. But the submodule should be git.git. I think\nthis is what I'd expect. I like the idea of bringing everything needed\nalong, and keeping it separate from the rest of the system. This avoids\nconflicts with, for example, cygwin.\n\nI don't think I would expect much more for a basic setup. All tests\nshould run, maybe some msysgit tests would be needed to test the \npitfalls\nwe'll discover; maybe not. I'll test XP 64 bit and Vista 64 bit \nbeginning\nof next week. Getting started hacking msysgit could be a bit easier.\nI didn't like the submodule problems I ran into and I still didn't find\nout how to push to the git mob branch.\n\nFor me a next step would be do some polishing. For example tune\ngit to integrate with other Windows tools, like what I proposed for\ngit-mergetool. I really started to love git when it launched a\ngraphical mergetool automatically for me. After that point I never\nedited merge markers again. Things I needed too much time before are\nnow running so smoothly. I think such a tight integration is really\nuseful to convince people. I'd also expect default choices to be\nreasonable. I'm not yet 100% sure, but my feeling it that core.autocrlf\nshould be set to true by default on Windows, globally. A bit more\nof msysgit specific documentation would also be good. Maybe we should\nadd a platform specific section to the user-manual. How could help\nin msysgit be handled? By a Windows help document?\n\nI could also think of a fail safe update, that allows to upgrade an\nexisting msysgit to a specific tag (maybe after stashing the current\ninstallation and reverting in case of problems).\n\nMaybe git gui could be integrated with the Windows Explorer and be\nlaunched on a directory. Maybe this is one of your evil plans. But\nthis is already more than I need.\n\nBack to the basic stuff.\nWhat do you think is needed to merge changes back to git.git?\nI counted approximately 20k diff lines (incl. context) between msysgit's\ngit master and git.git's master. At a first glance much of them seem to\nbe compatibility stuff.\n\n\tSteffen\n"},{"id":"50630","messageId":"Pine.LNX.4.64.0708130122200.7037@racer.site","threadId":"9422","inReplyTo":"EF7DFA5A-9C3A-4D0B-9533-D1D60AE4A44C@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-13T10:50:39Z","receivedAt":"2007-08-13T10:50:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 11 Aug 2007, Steffen Prohaska wrote:\n\n> I'm impressed. Pretty much everything I tried today worked for me. After \n> I got git gui running, and learned how to avoid pitfalls of git \n> submodule, development went smoothly.\n\nThanks!\n\n> I could also think of a fail safe update, that allows to upgrade an \n> existing msysgit to a specific tag (maybe after stashing the current \n> installation and reverting in case of problems).\n\nIt's pretty early to think about stable releases, let alone upgrades ;-)\n\n> Maybe git gui could be integrated with the Windows Explorer and be \n> launched on a directory. Maybe this is one of your evil plans. But this \n> is already more than I need.\n\nThat is already in the works. An alpha version is already working.\n\n> What do you think is needed to merge changes back to git.git? I counted \n> approximately 20k diff lines (incl. context) between msysgit's git \n> master and git.git's master. At a first glance much of them seem to be \n> compatibility stuff.\n\nIt is _all_ compatibility stuff.\n\nBasically, it all boils down to grabbing a specific part of the diff \nrelated to a certain concept (such as NO_IPV6), and whip the patch \n(series) into shape.\n\nSubmit it to git.git. Work on it until it is part of the official \ndistribution.\n\nContinue with the next part of the diff.\n\nCiao,\nDscho\n"},{"id":"50736","messageId":"e7bda7770708141704m587dfdbdqfbab51b8ac6fcff@mail.gmail.com","threadId":"9422","inReplyTo":"EF7DFA5A-9C3A-4D0B-9533-D1D60AE4A44C@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Torgil Svensson","fromEmail":"torgil.svensson@gmail.com","sentAt":"2007-08-15T00:04:53Z","receivedAt":"2007-08-15T00:04:53Z","isPatch":false,"sender":{"key":"torgil.svensson@gmail.com","avatar":null},"body":"On 8/11/07, Steffen Prohaska wrote:\n\n> >> [..list of tools and links]\n> >\n> > Thank you for the information! i'll check those up.\n>\n>\n> I hope to have an improved list on monday, sorted by priority of\n> the developers I'm working with.\n>\n> I thought I do some coding, to find out a bit more about the\n> stability of msysgit. So I started and added support for kdiff3\n> on Windows (see patches in separate mail).\n\nneat.The hardest part for me was to find out that I didn't have to\nconfigure anything or add a command line option to get kdiff3 running.\n(I cheated looking in the source, I think we should add #ifdef\n__MINGW32__ / #endif around the registry reading part.\n\nGood job!\n\n\n\n\n> I'm impressed. Pretty much everything I tried today worked for\n> me. After I got git gui running, and learned how to avoid pitfalls\n> of git submodule, development went smoothly. I pushed and pulled a\n> bit from linux and mac and did some coding. Thanks for the vim\n> setup!\n>\n> I think you (and more people I don't yet know) did a great job\n> with msysgit. I'd recommend it over cygwin's git, which caused\n> some trouble for me.\n\nThanks. I'm as fresh as you in msysgit development but it is quite\nstraightforward. I've fiddled around with cygwin/msys before but now I\nthink we're on to something useful.\n\n\n> > What do you include in the \"make windist\" installer and the \"Windows\n> > support\" ? Are you talking porcelain or plumbing?\n>\n> Hard to say. I believe now, from what I learned today, that the msysgit\n> approach is quite reasonable: Grouping all needed unix tools around a\n> submodule containing git. But the submodule should be git.git. I think\n> this is what I'd expect. I like the idea of bringing everything needed\n> along, and keeping it separate from the rest of the system. This avoids\n> conflicts with, for example, cygwin.\n\n\n> I don't think I would expect much more for a basic setup. All tests\n> should run, maybe some msysgit tests would be needed to test the\n> pitfalls\n\nI'm lacking several things. Many usability-glitches, some bugs, easy\naccess to documentation. Also we want to integrate the mingw git parts\ninto git.git so people can follow the official repo. etc..\n\n> I didn't like the submodule problems I ran into and I still didn't find\n> out how to push to the git mob branch.\n\nThis is weird. I haven't had such problems with this (dirty submodule\nin working dir), but that probably is because the supermodule doesn't\ndepend on files in the submodule [submodule \"make install\" copies\nfiles to the supermodule]. Otherwise we should be more dependent on a\nclean submodule state. I would though expect a \"git reset --hard\" to\nfix up the submodule for me.\n\n\n> [ many proposals for future work with msysgit]\n\nYeah. there's plenty of stuff to do. You could add this stuff to the\nissue tracker Dimitry has initiated.\n\n//Torgil\n"},{"id":"50747","messageId":"30FE2B1C-B651-4F1D-B5D9-CD3C3261F531@zib.de","threadId":"9422","inReplyTo":"e7bda7770708141704m587dfdbdqfbab51b8ac6fcff@mail.gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-15T05:22:50Z","receivedAt":"2007-08-15T05:22:50Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 15, 2007, at 2:04 AM, Torgil Svensson wrote:\n\n> On 8/11/07, Steffen Prohaska wrote:\n>\n>>>> [..list of tools and links]\n>>>\n>>> Thank you for the information! i'll check those up.\n>>\n>>\n>> I hope to have an improved list on monday, sorted by priority of\n>> the developers I'm working with.\n>>\n>> I thought I do some coding, to find out a bit more about the\n>> stability of msysgit. So I started and added support for kdiff3\n>> on Windows (see patches in separate mail).\n>\n> neat.The hardest part for me was to find out that I didn't have to\n> configure anything or add a command line option to get kdiff3 running.\n> (I cheated looking in the source, I think we should add #ifdef\n> __MINGW32__ / #endif around the registry reading part.\n\nWhat does __MINGW32__ mean for shell code? The registry reading\nshould just be ignored if registry access 'reg.exe' is not available.\n\nHowever, the code was not yet robust. I pushed the patch below to\n4msysgit.git's mob.\n\n\tSteffen\n\n\ncommit 816f61fecd9e90879afcbad9234f19bf6d982b76\nAuthor: Johannes Schmidt-Ehrenberg \nDate: Mon Aug 13 19:00:39 2007 +0200\n\n mergetool: fixed parsing of registry entry for kdiff3\n\n The old code failed on Windows Vista. The output of\n reg.exe or something else may be a bit different.\n This patch improves the parsing code to be more robust.\n\n Signed-off-by: Steffen Prohaska \n"},{"id":"50749","messageId":"85fy2l1i1g.fsf@lola.goethe.zz","threadId":"9422","inReplyTo":"30FE2B1C-B651-4F1D-B5D9-CD3C3261F531@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-15T05:30:19Z","receivedAt":"2007-08-15T05:30:19Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Steffen Prohaska writes:\n\n> Author: Johannes Schmidt-Ehrenberg \n> Date: Mon Aug 13 19:00:39 2007 +0200\n>\n> mergetool: fixed parsing of registry entry for kdiff3\n>\n> The old code failed on Windows Vista. The output of\n> reg.exe or something else may be a bit different.\n> This patch improves the parsing code to be more robust.\n\nI seem to remember that you can't rely on reg.exe being available on\nWindows. The Microsoft support pages talk about using regedit.exe\ninstead (which is quite more cumbersome).\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"50751","messageId":"ABA1D7D2-92A6-4E8C-AC36-93912621E3D4@zib.de","threadId":"9422","inReplyTo":"85fy2l1i1g.fsf@lola.goethe.zz","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-15T05:43:15Z","receivedAt":"2007-08-15T05:43:15Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 15, 2007, at 7:30 AM, David Kastrup wrote:\n\n> Steffen Prohaska writes:\n>\n>> Author: Johannes Schmidt-Ehrenberg \n>> Date: Mon Aug 13 19:00:39 2007 +0200\n>>\n>> mergetool: fixed parsing of registry entry for kdiff3\n>>\n>> The old code failed on Windows Vista. The output of\n>> reg.exe or something else may be a bit different.\n>> This patch improves the parsing code to be more robust.\n>\n> I seem to remember that you can't rely on reg.exe being available on\n> Windows. The Microsoft support pages talk about using regedit.exe\n> instead (which is quite more cumbersome).\n\nI successfully ran it on at least Windows XP and Vista. On Vista,\nit was present on a quite fresh system (Visual Studio not yet\ninstalled). So I'm quite confident that it's likely to be there.\n\nDo you have a reference? I searched msdn and was not able to\nimmediately find the recommendation you're referring to.\n\n\tSteffen\n"},{"id":"50755","messageId":"86d4xp471i.fsf@lola.quinscape.zz","threadId":"9422","inReplyTo":"ABA1D7D2-92A6-4E8C-AC36-93912621E3D4@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-15T06:59:37Z","receivedAt":"2007-08-15T06:59:37Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Steffen Prohaska writes:\n\n> On Aug 15, 2007, at 7:30 AM, David Kastrup wrote:\n>\n>> Steffen Prohaska writes:\n>>\n>>> Author: Johannes Schmidt-Ehrenberg \n>>> Date: Mon Aug 13 19:00:39 2007 +0200\n>>>\n>>> mergetool: fixed parsing of registry entry for kdiff3\n>>>\n>>> The old code failed on Windows Vista. The output of\n>>> reg.exe or something else may be a bit different.\n>>> This patch improves the parsing code to be more robust.\n>>\n>> I seem to remember that you can't rely on reg.exe being available on\n>> Windows. The Microsoft support pages talk about using regedit.exe\n>> instead (which is quite more cumbersome).\n>\n> I successfully ran it on at least Windows XP and Vista. On Vista,\n> it was present on a quite fresh system (Visual Studio not yet\n> installed). So I'm quite confident that it's likely to be there.\n>\n> Do you have a reference? I searched msdn and was not able to\n> immediately find the recommendation you're referring to.\n\n\n\n Q.\tWhat other tools are available for using the registry in batch?\n A.\t\n\n If you install the Support Tools from the Windows 2000 CD-ROM, you\n can use REG.EXE to Add, Delete, Copy, Compare, Export, Import,\n Load a Hive, Query, Save, Restore, and Unload a Hive. To install\n the Support Tools:\n\n 1.\n\n\n Insert the Windows 2000 CD-ROM into your CD-ROM drive.\n\n 2.\n\n\n Click Browse this CD, and then open the Support\\Tools folder.\n\n 3.\n\n\n Double-click Setup.exe, and follow the on-screen instructions.\n\n\nThat does not sound like one could rely on its presence out of the\nbox, at least on Windows 2000.\n\n-- \nDavid Kastrup\n"},{"id":"50757","messageId":"20070815073811.GL27913@spearce.org","threadId":"9422","inReplyTo":"86k5rx474o.fsf@lola.quinscape.zz","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-15T07:38:11Z","receivedAt":"2007-08-15T07:38:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Kastrup wrote:\n> Load a Hive, Query, Save, Restore, and Unload a Hive. To install\n> the Support Tools:\n> \n> 1.\n> \n> \n> Insert the Windows 2000 CD-ROM into your CD-ROM drive.\n\nIndeed, that step right there will stop many users cold in their\ntracks.\n\nWho the hell has their Windows 2000 CD-ROM handy? Or wants to open a\nCD-ROM drive? Or wants to wait for a 40x CD-ROM to spin up and copy\ndata? Who even still has a CD-ROM drive connected to a computer?\n(I usually don't have any optical media drive attached...)\n\nWhere's the damn URL to download setup.exe? Where's the webpage\nwith the Internet Explorer buffer overflow exploit to automatically\ninstall the software for the user? Why doesn't it create a thousand\nicons on the desktop, obscuring the user's picture of their kitty?\n\n;-)\n\n-- \nShawn.\n"},{"id":"50768","messageId":"30e4a070708150542m3f3f5c62l5e4bf5b3ff098b52@mail.gmail.com","threadId":"9422","inReplyTo":"20070815073811.GL27913@spearce.org","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-15T12:42:42Z","receivedAt":"2007-08-15T12:42:42Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 8/15/07, Shawn O. Pearce wrote:\n> David Kastrup wrote:\n> > Load a Hive, Query, Save, Restore, and Unload a Hive. To install\n> > the Support Tools:\n> >\n> > 1.\n> >\n> >\n> > Insert the Windows 2000 CD-ROM into your CD-ROM drive.\n>\n> Indeed, that step right there will stop many users cold in their\n> tracks.\n\nmaybe something like ...\n\ncase \"$(uname -o) in\n"},{"id":"50769","messageId":"30e4a070708150548r3234cd66yd4ee6a85989a98b1@mail.gmail.com","threadId":"9422","inReplyTo":"30e4a070708150542m3f3f5c62l5e4bf5b3ff098b52@mail.gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-15T12:48:04Z","receivedAt":"2007-08-15T12:48:04Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 8/15/07, Mark Levedahl wrote:\n> On 8/15/07, Shawn O. Pearce wrote:\n> > David Kastrup wrote:\n> > > Load a Hive, Query, Save, Restore, and Unload a Hive. To install\n> > > the Support Tools:\n> > >\n> > > 1.\n> > >\n> > >\n> > > Insert the Windows 2000 CD-ROM into your CD-ROM drive.\n> >\n> > Indeed, that step right there will stop many users cold in their\n> > tracks.\n>\nmaybe something like ...\n\ncase \"$(uname -s) in\n MSYS*)\n ;;\n *)\n ;;\nesac\n\nMark\n"},{"id":"50770","messageId":"3F9AF722-0610-4778-A244-DBE5A0918D0B@zib.de","threadId":"9422","inReplyTo":"30e4a070708150548r3234cd66yd4ee6a85989a98b1@mail.gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-15T13:06:58Z","receivedAt":"2007-08-15T13:06:58Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 15, 2007, at 2:48 PM, Mark Levedahl wrote:\n\n> On 8/15/07, Mark Levedahl wrote:\n>> On 8/15/07, Shawn O. Pearce wrote:\n>>> David Kastrup wrote:\n>>>> Load a Hive, Query, Save, Restore, and Unload a Hive. To \n>>>> install\n>>>> the Support Tools:\n>>>>\n>>>> 1.\n>>>>\n>>>>\n>>>> Insert the Windows 2000 CD-ROM into your CD-ROM drive.\n>>>\n>>> Indeed, that step right there will stop many users cold in their\n>>> tracks.\n>>\n> maybe something like ...\n>\n> case \"$(uname -s) in\n> MSYS*)\n> ;;\n> *)\n> ;;\n> esac\n\nIf reg.exe is not there kdiff3 will not be found. The code will\nalready be _ignored_. It's just not working.\n\nIt may make sense to use 'uname -s' to explicitly control that the\ncode is expected to work. This would allow to report errors if a\ncommand is missing. However, cluttering all shell scripts with\nuname's will likely become quite confusing.\n\nIf performance is a concern, we may execute uname -s only once\nin git-sh-setup and assign its return to something like GIT_UNAME.\nThis may save us a few forks, which are to my knowledge quite\nexpensive on Windows.\n\n\tSteffen\n"},{"id":"50844","messageId":"46C39A06.7020003@gmail.com","threadId":"9422","inReplyTo":"3F9AF722-0610-4778-A244-DBE5A0918D0B@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-16T00:27:50Z","receivedAt":"2007-08-16T00:27:50Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Steffen Prohaska wrote:\n>\n> If reg.exe is not there kdiff3 will not be found. The code will\n> already be _ignored_. It's just not working.\nI'm really thinking forward to when you try to reintegrate this into \ngit.git: Platform specific code needs to be wrapped with a test that has \na known result on all platforms.\n\nMark\n"},{"id":"50850","messageId":"3CDBDF39-F6FB-411D-9691-3146B882B8EC@zib.de","threadId":"9422","inReplyTo":"46C39A06.7020003@gmail.com","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-16T06:04:48Z","receivedAt":"2007-08-16T06:04:48Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 16, 2007, at 2:27 AM, Mark Levedahl wrote:\n\n> Steffen Prohaska wrote:\n>>\n>> If reg.exe is not there kdiff3 will not be found. The code will\n>> already be _ignored_. It's just not working.\n> I'm really thinking forward to when you try to reintegrate this \n> into git.git: Platform specific code needs to be wrapped with a \n> test that has a known result on all platforms.\n\nI thought about that, too.\n\nThe code works on _all_ platforms as follows:\n- if 'REG' is available, its output is parsed for the diffcommand;\n- if 'REG' is not available the code is ignored.\n\nThe only problem I see with this approach is that the code does not\ntest if 'REG' was present and returned an error for an unknown reason.\nbtw, in merge tool we would probably ignore such an error anyway.\n\n\nWhat does 'platform specific' mean? Is MINGW the platform? If so,\nhow about Cygwin? Or is Windows the platform?\n\nWindows will often be the right choice.\n\nSo how do we test for Windows?\n\nOn my machine uname returns the following in Cygwin and Mingw\n- CYGWIN_NT-5.1\n- MINGW32_NT-5.1\n\n\nThe patch I sent does not test for platforms, but assumes that 'REG'\nwill only be available on Windows. Errors will just be ignored, which\nis is not perfect. This could be improved by testing first if 'REG' is\navailable and if so report errors returned by REG.\n\nAssuming that 'REG' is only available on Windows and has a defined\nmeaning seems to be reasonable assumption to me. I don't see the need\nto test which platform the script is running on. Testing if 'REG' is\navailable seems to be sufficient.\n\n\tSteffen\n"},{"id":"50879","messageId":"30e4a070708160455t78eae31cx3e6d3a7203d0b4b8@mail.gmail.com","threadId":"9422","inReplyTo":"3CDBDF39-F6FB-411D-9691-3146B882B8EC@zib.de","subject":"Re: git on Cygwin: Not a valid object name HEAD","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2007-08-16T11:55:55Z","receivedAt":"2007-08-16T11:55:55Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"> Assuming that 'REG' is only available on Windows and has a defined\n> meaning seems to be reasonable assumption to me. I don't see the need\n> to test which platform the script is running on. Testing if 'REG' is\n> available seems to be sufficient.\n>\n> Steffen\n>\n\nI don't think that REG is a a name reserved for use only on Windows\nthat could never exist on another box. Its meaning is undefined\noutside of Windows. Undefined means unreliable and therefore, not\nuseful as a test to decide what to do on arbitrary platforms. Also, on\nCygwin you would use regtool and parse things differently anyway,\nwhile Cygwin users tend to be educable enough that if they want to use\nkdiff or whatever, they'll symlink it or otherwise put it on their\npath.\n\nMark\n"}]}