{"thread":{"id":"1925","subject":"git 0.99.7b doesn't build on Cygwin","startedAt":"2005-09-23T13:33:46Z","lastAt":"2005-09-26T22:15:17Z","messageCount":38,"participants":["Peter TB Brett","Johannes Schindelin","Martin Langhoff","Petr Baudis","Linus Torvalds","Junio C Hamano","Davide Libenzi","Daniel Barkalow","Giuseppe Bilotta","Jon Loeliger","H. Peter Anvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9184","messageId":"ud5mznc1x.fsf@peter-b.co.uk","threadId":"1925","inReplyTo":null,"subject":"git 0.99.7b doesn't build on Cygwin","fromName":"Peter TB Brett","fromEmail":"peter@peter-b.co.uk","sentAt":"2005-09-23T13:33:46Z","receivedAt":"2005-09-23T13:33:46Z","isPatch":false,"sender":{"key":"peter@peter-b.co.uk","avatar":"https://gravatar.com/avatar/6b467f6653937dfb2de5b1cdd273b5f6c8f2dc7f4b9f75cb2ba27e62fae695fd?d=mp&s=160"},"body":"\nHi folks,\n\nI wanted to use git on a Windows-based project (yes, there are some\nout there still), so I fired up my Cygwin xterm, untarred the git\nsources and totally failed to succeed in building them:\n\n ---- ----\n\n$ make\ngcc -o apply.o -c -g -O2 -Wall '-DSHA1_HEADER=' apply.c\ngcc -o blob.o -c -g -O2 -Wall '-DSHA1_HEADER=' blob.c\ngcc -o commit.o -c -g -O2 -Wall '-DSHA1_HEADER=' commit.c\ngcc -o connect.o -c -g -O2 -Wall '-DSHA1_HEADER=' connect.c\nconnect.c: In function `git_tcp_connect':\nconnect.c:298: error: storage size of 'hints' isn't known\nconnect.c:322: warning: implicit declaration of function `getaddrinfo'\nconnect.c:324: warning: implicit declaration of function `gai_strerror'\nconnect.c:324: warning: format argument is not a pointer (arg 3)\nconnect.c:326: error: dereferencing pointer to incomplete type\nconnect.c:327: error: dereferencing pointer to incomplete type\nconnect.c:327: error: dereferencing pointer to incomplete type\nconnect.c:327: error: dereferencing pointer to incomplete type\nconnect.c:330: error: dereferencing pointer to incomplete type\nconnect.c:330: error: dereferencing pointer to incomplete type\nconnect.c:338: warning: implicit declaration of function `freeaddrinfo'\nconnect.c:298: warning: unused variable `hints'\nmake: *** [connect.o] Error 1\n\n$ gcc --version\ngcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)\n...\n\n ---- ----\n\nIt looks like the sort of problems I get when I'm missing header\nfiles, but all the headers #included by connect.c are present on my\nsystem, so I'm really not sure what's going on there...\n\nPeter\n\n\nP.S. Please Cc: me on any replies, I'm not subscribed to the list.\n\n\n-- \nQuake II build tools: http://peter-b.co.uk/\nLatest QuArK: http://quark.sourceforge.net/LatestVersion\n\nv2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4\n hackerkey.com\n"},{"id":"9185","messageId":"Pine.LNX.4.63.0509231537390.11109@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1925","inReplyTo":"ud5mznc1x.fsf@peter-b.co.uk","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-09-23T13:44:09Z","receivedAt":"2005-09-23T13:44:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Sep 2005, Peter TB Brett wrote:\n\n> I wanted to use git on a Windows-based project (yes, there are some\n> out there still), so I fired up my Cygwin xterm, untarred the git\n> sources and totally failed to succeed in building them:\n\nAlso see my mail regarding cygwin:\n\nhttp://www.gelato.unsw.edu.au/archives/git/0508/7956.html\n\n> gcc -o connect.o -c -g -O2 -Wall '-DSHA1_HEADER=' connect.c\n> connect.c: In function `git_tcp_connect':\n> connect.c:298: error: storage size of 'hints' isn't known\n> connect.c:322: warning: implicit declaration of function `getaddrinfo'\n> connect.c:324: warning: implicit declaration of function `gai_strerror'\n> [...]\n\nThis is the IPv6 stuff. There are patches to cygwin to support IPv6 \nsomewhere, but they haven't made it into mainline.\n\nAs for the other problem I mentioned in my original mail:\n\nIt seems that the fixup of the mmap()ed regions after a fork() does not \nwork properly in cygwin. Remember that cygwin just wraps the non-POSIX \nWin32API and tries to make it sort of POSIX compliant. The problem is that \nWin32API lacks a proper fork(). This is therefore emulated, and after \nthat, all the mmap()ed regions have to be mapped again. That fails.\n\nSidenote: I ran it inside gdb, and it worked fine! So I tried to recompile \nthe cygwin1.dll, but that wrecked my whole installation of cygwin and I \nspent 2 hours just to be able to \"gcc -o\" again.\n\nCiao,\nDscho\n"},{"id":"9186","messageId":"14403.62.254.128.6.1127483455.squirrel@mail.twu.net","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509231537390.11109@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Peter TB Brett","fromEmail":"peter@peter-b.co.uk","sentAt":"2005-09-23T13:50:55Z","receivedAt":"2005-09-23T13:50:55Z","isPatch":false,"sender":{"key":"peter@peter-b.co.uk","avatar":"https://gravatar.com/avatar/6b467f6653937dfb2de5b1cdd273b5f6c8f2dc7f4b9f75cb2ba27e62fae695fd?d=mp&s=160"},"body":"\nJohannes Schindelin wrote:\n\n>> I wanted to use git on a Windows-based project (yes, there are some\n>> out there still), so I fired up my Cygwin xterm, untarred the git\n>> sources and totally failed to succeed in building them:\n>\n> Also see my mail regarding cygwin:\n>\n> http://www.gelato.unsw.edu.au/archives/git/0508/7956.html\n\nYes. I found that just after I'd spammed the list.\n\n> This is the IPv6 stuff. There are patches to cygwin to support IPv6\n> somewhere, but they haven't made it into mainline.\n>\n> As for the other problem I mentioned in my original mail:\n>\n> It seems that the fixup of the mmap()ed regions after a fork() does not\n> work properly in cygwin. Remember that cygwin just wraps the non-POSIX\n> Win32API and tries to make it sort of POSIX compliant. The problem is that\n> Win32API lacks a proper fork(). This is therefore emulated, and after\n> that, all the mmap()ed regions have to be mapped again. That fails.\n\nHmph. Sounds like I'm stuffed.\n\nAh well, I'll just have to use something else -- I know Mercurial works on\nWindows. To be honest, I'd prefer to use git though; I've used it on\nother projects and it's really nice.\n\nAh well, can't have everything you want all of the time, neh?\n\nPeter\n\n\n-- \nQuake II build tools: http://peter-b.co.uk/\nLatest QuArK: http://quark.sourceforge.net/LatestVersion\n\nv2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4\n hackerkey.com\n"},{"id":"9200","messageId":"46a038f905092315081de776c3@mail.gmail.com","threadId":"1925","inReplyTo":"14403.62.254.128.6.1127483455.squirrel@mail.twu.net","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-09-23T22:08:28Z","receivedAt":"2005-09-23T22:08:28Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/24/05, Peter TB Brett wrote:\n> Ah well, I'll just have to use something else -- I know Mercurial works on\n> Windows. To be honest, I'd prefer to use git though; I've used it on\n> other projects and it's really nice.\n\nPetr Baudis was working on a Mercurial-GIT gateway which could be\nuseful, or perhaps you can use tailor.py. OTOH, if you have a unix\nmachine in the network, you can probably make cretive use of samba...\n\ncheers,\n\n\nmartin\n"},{"id":"9204","messageId":"20050923223452.GH10255@pasky.or.cz","threadId":"1925","inReplyTo":"46a038f905092315081de776c3@mail.gmail.com","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-23T22:34:52Z","receivedAt":"2005-09-23T22:34:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Sep 24, 2005 at 12:08:28AM CEST, I got a letter\nwhere Martin Langhoff told me that...\n> On 9/24/05, Peter TB Brett wrote:\n> > Ah well, I'll just have to use something else -- I know Mercurial works on\n> > Windows. To be honest, I'd prefer to use git though; I've used it on\n> > other projects and it's really nice.\n> \n> Petr Baudis was working on a Mercurial-GIT gateway which could be\n> useful, or perhaps you can use tailor.py. OTOH, if you have a unix\n> machine in the network, you can probably make cretive use of samba...\n\nClarification: that was a Monotone-GIT gateway.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9208","messageId":"Pine.LNX.4.58.0509231647300.3308@g5.osdl.org","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509231537390.11109@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-24T00:09:11Z","receivedAt":"2005-09-24T00:09:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 23 Sep 2005, Johannes Schindelin wrote:\n> \n> It seems that the fixup of the mmap()ed regions after a fork() does not \n> work properly in cygwin. Remember that cygwin just wraps the non-POSIX \n> Win32API and tries to make it sort of POSIX compliant. The problem is that \n> Win32API lacks a proper fork(). This is therefore emulated, and after \n> that, all the mmap()ed regions have to be mapped again. That fails.\n\nNow, I'm not a big fan of windows (\"No, really? Tell us more!\") but I'd \nactually like it if the _core_ git stuff worked in as wide a variety of \nsituations as possible. Screw the shell scripts and the daemon or \nsecondary things like that which windows users might as well generate \ntheir own stuff for, but I'd hope the really core stuff would work.\n\nIf I understood correctly, you said that \"git-diff-tree\" doesn't work due\nto the fork/mmap issue. Now, I assume that means that it's the builtin\ndiff that has problems. \n\nAs far as I can tell, we can solve that two ways:\n\n - make Windows always use the external diff program. That may be the \n right thing to do, since then the fork() just turns into a regular \n fork+exec, which is how windows works anyway.\n\n - look at doing the diff internally.\n\nI'm wondering if there is some stupid way to turn a diff generated by \ndiff_delta() into a line-based one? If you have the original file and the \nxdiff, I think we should be able to just walk the original file and output \na unified diff.\n\nDavide, maybe I'm being stupid, but I'm thinking that it might be possible\nto generate a -u3 diff by basically walking the xdiff file in a linear\nfashion: if the edits are in strictly ascending order, we could walk the\noriginal file one line at a time, and keeping a buffer of the three last\nlines. Then, when the file offset hits the next \"edit\" in the xdiff, we\nstart generating a line-based diff (and use the previous three lines as\nthe context).\n\nDoes that sound possible? Maybe somebody has even done it? Is it a stupid \nidea?\n\nI realize that it might not generate the same diff as GNU diff would do, \nand maybe it's really nasty, but it sounds like it _could_ be a \"cheap\" \nway of generating diffs, considering that we have something that already \ngenerates xdiffs..\n\n\t\tLinus\n"},{"id":"9209","messageId":"Pine.LNX.4.58.0509231737140.3308@g5.osdl.org","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509231647300.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-24T00:43:20Z","receivedAt":"2005-09-24T00:43:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 23 Sep 2005, Linus Torvalds wrote:\n> \n> Davide, maybe I'm being stupid, but I'm thinking that it might be possible\n> to generate a -u3 diff by basically walking the xdiff file in a linear\n> fashion: if the edits are in strictly ascending order\n\nAhh, no. Looking at the xdiff format, the edits are strictly ascending in \nthe destination, but they may take stuff from the source in any order, so \nit's not like you can generate a diff from it by just walking it.\n\nOh, well. I guess we're better off just using the external diff command, \neven if it is slower to execve an external diff. \n\nThe GNU diff sources are hard enough to read that I don't think we want to \ntry to merge the unified diff generation from there.\n\n\t\tLinus\n"},{"id":"9211","messageId":"Pine.LNX.4.63.0509240305450.26220@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509231647300.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-09-24T01:13:31Z","receivedAt":"2005-09-24T01:13:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Sep 2005, Linus Torvalds wrote:\n\n> On Fri, 23 Sep 2005, Johannes Schindelin wrote:\n> > \n> > It seems that the fixup of the mmap()ed regions after a fork() does not \n> > work properly in cygwin. Remember that cygwin just wraps the non-POSIX \n> > Win32API and tries to make it sort of POSIX compliant. The problem is that \n> > Win32API lacks a proper fork(). This is therefore emulated, and after \n> > that, all the mmap()ed regions have to be mapped again. That fails.\n> \n> Now, I'm not a big fan of windows (\"No, really? Tell us more!\") but I'd \n> actually like it if the _core_ git stuff worked in as wide a variety of \n> situations as possible.\n\nIt is sure worth to try to be as portable as possible. Just look at the \nbugs found by running git on x86_64 (for example by HPA), which were not \napparent from x86 or PowerPC.\n\n> Screw the shell scripts and the daemon or secondary things like that \n> which windows users might as well generate their own stuff for, but I'd \n> hope the really core stuff would work.\n\nWhoa, slow! The shell scripts and the networking are important parts even \nof the core git suite. Without them, work is next to impossible.\n\n> If I understood correctly, you said that \"git-diff-tree\" doesn't work due\n> to the fork/mmap issue. Now, I assume that means that it's the builtin\n> diff that has problems. \n\nNo. It means that there is something weird going on inside cygwin1.dll. \nThis library works perfectly when the program is run inside gdb. Which \ncould well mean some timing issue. Unfortunately, I have problems \nrebuilding cygwin1.dll, and therefore cannot debug in detail.\n\nBTW I am fairly convinced that the same issues would trouble a git-pull, \nonce the networking is running, since the pack transfer relies on \nfork()ing.\n\n> I'm wondering if there is some stupid way to turn a diff generated by \n> diff_delta() into a line-based one? If you have the original file and the \n> xdiff, I think we should be able to just walk the original file and output \n> a unified diff.\n\nIt sure would be nice to have a unified diff generator included, but I \ndoubt that a reliable (=simple) one is easy to come by.\n\nCiao,\nDscho\n"},{"id":"9218","messageId":"Pine.LNX.4.58.0509231935360.3308@g5.osdl.org","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509240305450.26220@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-24T02:46:47Z","receivedAt":"2005-09-24T02:46:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 24 Sep 2005, Johannes Schindelin wrote:\n> \n> BTW I am fairly convinced that the same issues would trouble a git-pull, \n> once the networking is running, since the pack transfer relies on \n> fork()ing.\n\nI'm not sure.\n\nAlmost all other fork() users end up doing a more-or-less immediate \nexecve() after the fork. Yes, they do some other minor setup, but not a \nwhole lot.\n\nThe diff.c fork() is somewhat different. It actually ends up doing malloc \nand stdio IO before it actually gets to the exec(), so that one is more \nlikely to hit any bugs in the fork() implementation.\n\nActually, looking a bit closer, the create_pack_file() thing also does \nmalloc inside the child, but at least there it would be trivial to move \nthat argument setup code into the parent.\n\nBut looking at send_pack() or fetch_pack(), for example, they are both\n_very_ traditional fork()+exec() calls, with just a few close() calls in\nbetween.\n\nLooking a bit closer at the diff() usage, I actually think that we could \nmove the fork() closer to the exec - we'd just have to move it _into_ all \nthe different cases (ie you'd have two different fork() calls: one for \nthe \"builtin\" case, one for the external pgm case, but then the child in \nboth cases would be very simple).\n\nOh. Actually, I wonder if we could mke them \"vfork()\" calls. Does anybody \nknow if cygwin has an easier time with vfork() + eventual exec? That \n_should_ map better to a non-UNIX process model, so maybe we could do it \nthat way?\n\n> It sure would be nice to have a unified diff generator included, but I \n> doubt that a reliable (=simple) one is easy to come by.\n\nYeah, I looked at GNU diffutils, and I had to rinse out my eyes with soap \nand water.\n\n\t\tLinus\n"},{"id":"9219","messageId":"7vaci36u95.fsf@assigned-by-dhcp.cox.net","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509231935360.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-24T03:04:54Z","receivedAt":"2005-09-24T03:04:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Looking a bit closer at the diff() usage, I actually think that we could \n> move the fork() closer to the exec - we'd just have to move it _into_ all \n> the different cases (ie you'd have two different fork() calls: one for \n> the \"builtin\" case, one for the external pgm case, but then the child in \n> both cases would be very simple).\n\nLooking back at what I did in the diff.c, I actually think the\npart near fork() is a total crap ;-).\n\nOriginally I intended to do more work in the child process (this\nis totally opposite of what is being proposed now), for example\nrunning prepare_temp_file() after child forked, so that the\nparent process does not have to worry about using memory for\nexpanded blob to be written out to the temporary file and then\nlater forgetting to free it ;-), but it seems the parent is\ndoing more work than I intended to. I honestly think that the\npart of the code is ancient enough to deserve a major facelift.\n"},{"id":"9220","messageId":"Pine.LNX.4.63.0509232155150.30718@localhost.localdomain","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509231647300.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-24T05:11:22Z","receivedAt":"2005-09-24T05:11:22Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Fri, 23 Sep 2005, Linus Torvalds wrote:\n\n>\n>\n> On Fri, 23 Sep 2005, Johannes Schindelin wrote:\n>>\n>> It seems that the fixup of the mmap()ed regions after a fork() does not\n>> work properly in cygwin. Remember that cygwin just wraps the non-POSIX\n>> Win32API and tries to make it sort of POSIX compliant. The problem is that\n>> Win32API lacks a proper fork(). This is therefore emulated, and after\n>> that, all the mmap()ed regions have to be mapped again. That fails.\n>\n> Now, I'm not a big fan of windows (\"No, really? Tell us more!\") but I'd\n> actually like it if the _core_ git stuff worked in as wide a variety of\n> situations as possible. Screw the shell scripts and the daemon or\n> secondary things like that which windows users might as well generate\n> their own stuff for, but I'd hope the really core stuff would work.\n>\n> If I understood correctly, you said that \"git-diff-tree\" doesn't work due\n> to the fork/mmap issue. Now, I assume that means that it's the builtin\n> diff that has problems.\n\nStay away from Cygwin if you use extensively fork(), since it becomes dog \nslow (the fork() implementation on Cygwin involves creating a new \nsuspended task, *copy* - not COW - the *whole* VM space to the child, \nand resuming it). Actually, the whole Cygwin in general is dog slow, \nespecially on FS operations (and git likes them). If you really like to \nhave Windows support (uuu hoo WinTorvalds) you might be better using a \nsmall compat layer (should be fairly small for git).\n\n\n\n> As far as I can tell, we can solve that two ways:\n>\n> - make Windows always use the external diff program. That may be the\n> right thing to do, since then the fork() just turns into a regular\n> fork+exec, which is how windows works anyway.\n>\n> - look at doing the diff internally.\n>\n> I'm wondering if there is some stupid way to turn a diff generated by\n> diff_delta() into a line-based one? If you have the original file and the\n> xdiff, I think we should be able to just walk the original file and output\n> a unified diff.\n>\n> Davide, maybe I'm being stupid, but I'm thinking that it might be possible\n> to generate a -u3 diff by basically walking the xdiff file in a linear\n> fashion: if the edits are in strictly ascending order, we could walk the\n> original file one line at a time, and keeping a buffer of the three last\n> lines. Then, when the file offset hits the next \"edit\" in the xdiff, we\n> start generating a line-based diff (and use the previous three lines as\n> the context).\n>\n> Does that sound possible? Maybe somebody has even done it? Is it a stupid\n> idea?\n>\n> I realize that it might not generate the same diff as GNU diff would do,\n> and maybe it's really nasty, but it sounds like it _could_ be a \"cheap\"\n> way of generating diffs, considering that we have something that already\n> generates xdiffs..\n\nHehe, the same library from where Nicolas lifted the code for the binary \ndiff, has a totally portable diff/patch APIs (on top of xdiff/xpach):\n\nhttp://www.xmailserver.org/xdiff.html\n\nGenerating text diffs, unfortunately is quite more complex than binary \nones. Libxdiff uses the same algorithm of GNU diff (Eugene W. Myers). The \nlibrary has zero dependency other than ANSI C. Another alternative, IIRC \nsomeone made a library by wrapping the diffutil stuff, but I do not \nremeber where it was.\n\n\n\n- Davide\n"},{"id":"9221","messageId":"Pine.LNX.4.63.0509232220330.30718@localhost.localdomain","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509231935360.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-24T05:26:43Z","receivedAt":"2005-09-24T05:26:43Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Fri, 23 Sep 2005, Linus Torvalds wrote:\n\n> But looking at send_pack() or fetch_pack(), for example, they are both\n> _very_ traditional fork()+exec() calls, with just a few close() calls in\n> between.\n>\n> Looking a bit closer at the diff() usage, I actually think that we could\n> move the fork() closer to the exec - we'd just have to move it _into_ all\n> the different cases (ie you'd have two different fork() calls: one for\n> the \"builtin\" case, one for the external pgm case, but then the child in\n> both cases would be very simple).\n>\n> Oh. Actually, I wonder if we could mke them \"vfork()\" calls. Does anybody\n> know if cygwin has an easier time with vfork() + eventual exec? That\n> _should_ map better to a non-UNIX process model, so maybe we could do it\n> that way?\n\nIf you have only to run diff/patch, just use the native Win32 CreateProcess().\nYou abstract that on a git_exec(), and you use fork/exec on Unix and \nCreateProcess() on Winblows. If fork() is slow on Cygwin, fork+exec is \npathetic. They do all that work to give you a fork(), and you throw it \naway with an exec().\n\n\n- Davide\n"},{"id":"9233","messageId":"Pine.LNX.4.58.0509241102450.3308@g5.osdl.org","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509232220330.30718@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-24T18:10:14Z","receivedAt":"2005-09-24T18:10:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 23 Sep 2005, Davide Libenzi wrote:\n> \n> If you have only to run diff/patch, just use the native Win32 CreateProcess().\n> You abstract that on a git_exec(), and you use fork/exec on Unix and \n> CreateProcess() on Winblows. If fork() is slow on Cygwin, fork+exec is \n> pathetic. They do all that work to give you a fork(), and you throw it \n> away with an exec().\n\nCreateProcess doesn't work all that well, since we want to dup file \ndescriptors around and close them in the child.\n\nIn general, CreateProcess() is a totally crap interface. I realize it's \ncommon (and especially in the VMS/Windows world it's how things are done), \nbut hey, at that point it's better if somebody just waits until git is \nstable, and just makes a totally separate \"git for windows\" thing. The \ninterfaces are certainly simple. There's no point in trying to maintain \none tree.\n\nHowever, vfork() really _is_ a nice interface. It's faster even on UNIX,\nand at least in theory it should be possible to do an efficient vfork() \nimplementation on top of crap like windows. Does cygwin support that well?\n\nYes, git uses lots of filesystem stuff, and they suck under windows. Maybe \ncygwin adds its own overhead, but from everything I've ever been able to \ntell, filesystem access sucks under Windows regardless of any cygwin \nstuff. Add to an already slow FS interface the fact that virus checkers \ntend to hook into it and make it _even_slower_, and hey, you have a truly \nsucky OS. \n\nBut at least with pack-files, the filesystem access patterns are much \nless common. Opening one pack-file and mapping it gets the FS out of the \nway. So I don't think that's necessarily a huge problem.\n\n\t\tLinus\n"},{"id":"9236","messageId":"Pine.LNX.4.63.0509241129300.31327@localhost.localdomain","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509241102450.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-24T19:12:38Z","receivedAt":"2005-09-24T19:12:38Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Sat, 24 Sep 2005, Linus Torvalds wrote:\n\n>\n>\n> On Fri, 23 Sep 2005, Davide Libenzi wrote:\n>>\n>> If you have only to run diff/patch, just use the native Win32 CreateProcess().\n>> You abstract that on a git_exec(), and you use fork/exec on Unix and\n>> CreateProcess() on Winblows. If fork() is slow on Cygwin, fork+exec is\n>> pathetic. They do all that work to give you a fork(), and you throw it\n>> away with an exec().\n>\n> CreateProcess doesn't work all that well, since we want to dup file\n> descriptors around and close them in the child.\n\nYou can do that (dup stuff and pass them around) even with CreateProcess(),\nif you want. Yes, the interface sucks (zillions of parameters/flags) ;)\n\n\n\n> In general, CreateProcess() is a totally crap interface. I realize it's\n> common (and especially in the VMS/Windows world it's how things are done),\n> but hey, at that point it's better if somebody just waits until git is\n> stable, and just makes a totally separate \"git for windows\" thing. The\n> interfaces are certainly simple. There's no point in trying to maintain\n> one tree.\n>\n> However, vfork() really _is_ a nice interface. It's faster even on UNIX,\n> and at least in theory it should be possible to do an efficient vfork()\n> implementation on top of crap like windows. Does cygwin support that well?\n>\n> Yes, git uses lots of filesystem stuff, and they suck under windows. Maybe\n> cygwin adds its own overhead, but from everything I've ever been able to\n> tell, filesystem access sucks under Windows regardless of any cygwin\n> stuff. Add to an already slow FS interface the fact that virus checkers\n> tend to hook into it and make it _even_slower_, and hey, you have a truly\n> sucky OS.\n\nI also realized that git plays/handles with unix permissions too, and this \nmight make the \"interface layer\" not so small. Dunno about vfork() on \nCygwin, but if you really care about performance on Windows, I'd rather \nremove the external program execution and use an in-process diff library.\n\n\n\n- Davide\n"},{"id":"9238","messageId":"7vbr2iw6l3.fsf@assigned-by-dhcp.cox.net","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509241129300.31327@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-24T20:31:36Z","receivedAt":"2005-09-24T20:31:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Making really really core part usable on Windows would not need\nthis, but there is another thing: .git/HEAD symlink.\n \n"},{"id":"9239","messageId":"Pine.LNX.4.63.0509241426240.16554@localhost.localdomain","threadId":"1925","inReplyTo":"7vbr2iw6l3.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-24T21:28:29Z","receivedAt":"2005-09-24T21:28:29Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Sat, 24 Sep 2005, Junio C Hamano wrote:\n\n> Making really really core part usable on Windows would not need\n> this, but there is another thing: .git/HEAD symlink.\n\nStarting from Win2k, they *finally* added:\n\nhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp\n\n\n\n- Davide\n"},{"id":"9241","messageId":"7vhdcauokf.fsf@assigned-by-dhcp.cox.net","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509241426240.16554@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-24T21:46:08Z","receivedAt":"2005-09-24T21:46:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Davide Libenzi writes:\n\n> On Sat, 24 Sep 2005, Junio C Hamano wrote:\n>\n>> Making really really core part usable on Windows would not need\n>> this, but there is another thing: .git/HEAD symlink.\n>\n> Starting from Win2k, they *finally* added:\n\nAh, that's good to know.\n"},{"id":"9242","messageId":"7vd5myuoi0.fsf@assigned-by-dhcp.cox.net","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509241426240.16554@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-24T21:47:35Z","receivedAt":"2005-09-24T21:47:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Davide Libenzi writes:\n\n> On Sat, 24 Sep 2005, Junio C Hamano wrote:\n>\n>> Making really really core part usable on Windows would not need\n>> this, but there is another thing: .git/HEAD symlink.\n>\n> Starting from Win2k, they *finally* added:\n>\n> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp\n\nIt talks about \"a hard link\". Can we readlink it?\n"},{"id":"9243","messageId":"Pine.LNX.4.63.0509241451510.16554@localhost.localdomain","threadId":"1925","inReplyTo":"7vd5myuoi0.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-24T21:52:39Z","receivedAt":"2005-09-24T21:52:39Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Sat, 24 Sep 2005, Junio C Hamano wrote:\n\n> Davide Libenzi writes:\n>\n>> On Sat, 24 Sep 2005, Junio C Hamano wrote:\n>>\n>>> Making really really core part usable on Windows would not need\n>>> this, but there is another thing: .git/HEAD symlink.\n>>\n>> Starting from Win2k, they *finally* added:\n>>\n>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp\n>\n> It talks about \"a hard link\". Can we readlink it?\n\nNope. It's an hardlink (ala link(2)).\n\n\n- Davide\n"},{"id":"9245","messageId":"Pine.LNX.4.58.0509241524270.3308@g5.osdl.org","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509241426240.16554@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-24T22:26:02Z","receivedAt":"2005-09-24T22:26:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 24 Sep 2005, Davide Libenzi wrote:\n> \n> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp\n\nDon't you mean\n\n\thttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp\n\nrather?\n\nIt mentions longhorn.\n\n\t\tLinus\n"},{"id":"9246","messageId":"Pine.LNX.4.58.0509241526180.3308@g5.osdl.org","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509241524270.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-24T22:27:34Z","receivedAt":"2005-09-24T22:27:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 24 Sep 2005, Linus Torvalds wrote:\n> \n> It mentions longhorn.\n\nAnyway, regardless, we could certainly make HEAD be a regular file \ncontaining the name of the head instead.\n\nIt probably wouldn't even require a whole lot of changes. HEAD already \nends up getting some special attention, since most of the things that look \nfor refs only look inside the .git/refs directory.\n\n\t\tLinus\n"},{"id":"9247","messageId":"Pine.LNX.4.63.0509241540170.16554@localhost.localdomain","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509241524270.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-24T22:41:27Z","receivedAt":"2005-09-24T22:41:27Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Sat, 24 Sep 2005, Linus Torvalds wrote:\n\n>\n>\n> On Sat, 24 Sep 2005, Davide Libenzi wrote:\n>>\n>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp\n>\n> Don't you mean\n>\n> \thttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp\n>\n> rather?\n>\n> It mentions longhorn.\n\nHah, didn't know this one. Requiring LongHorn is pretty strict though ;)\n\n\n- Davide\n"},{"id":"9248","messageId":"Pine.LNX.4.63.0509242248440.23242@iabervon.org","threadId":"1925","inReplyTo":"7vbr2iw6l3.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-25T03:04:46Z","receivedAt":"2005-09-25T03:04:46Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 24 Sep 2005, Junio C Hamano wrote:\n\n> Making really really core part usable on Windows would not need\n> this, but there is another thing: .git/HEAD symlink.\n\nCygwin supports symlinks without underlying filesystem support. It does \nbasically the standard UNIX thing for symlinks, but inefficiently in \nuserspace.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"9254","messageId":"7vzmq1twh5.fsf@assigned-by-dhcp.cox.net","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509231737140.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-25T07:52:54Z","receivedAt":"2005-09-25T07:52:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> The GNU diff sources are hard enough to read that I don't think we want to \n> try to merge the unified diff generation from there.\n\nI was talking with GNU diff maintainer and his impression was\nthat CVS folks may have done enough libification -- I'll find\ntime to look at CVS code and see how much damage we are talking\nabout.\n"},{"id":"9259","messageId":"Pine.LNX.4.63.0509251745160.17672@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1925","inReplyTo":"7vzmq1twh5.fsf@assigned-by-dhcp.cox.net","subject":"Implementing diff, was Re: git 0.99.7b doesn't build on Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-09-25T15:47:17Z","receivedAt":"2005-09-25T15:47:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Sep 2005, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > The GNU diff sources are hard enough to read that I don't think we want to \n> > try to merge the unified diff generation from there.\n> \n> I was talking with GNU diff maintainer and his impression was\n> that CVS folks may have done enough libification -- I'll find\n> time to look at CVS code and see how much damage we are talking\n> about.\n\nI am not sure if it would be wise to completely do away with the current \nmethod: Often, I call git-diff with my own wdiff-helper. Also, options \nlike \"-b\" to diff are very useful, and would have to be implemented, too.\n\nCiao,\nDscho\n"},{"id":"9260","messageId":"Pine.LNX.4.63.0509250854570.22725@localhost.localdomain","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509251745160.17672@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: Implementing diff, was Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-25T16:08:20Z","receivedAt":"2005-09-25T16:08:20Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Sun, 25 Sep 2005, Johannes Schindelin wrote:\n\n>> Linus Torvalds writes:\n>>\n>>> The GNU diff sources are hard enough to read that I don't think we want to\n>>> try to merge the unified diff generation from there.\n>>\n>> I was talking with GNU diff maintainer and his impression was\n>> that CVS folks may have done enough libification -- I'll find\n>> time to look at CVS code and see how much damage we are talking\n>> about.\n>\n> I am not sure if it would be wise to completely do away with the current\n> method: Often, I call git-diff with my own wdiff-helper. Also, options\n> like \"-b\" to diff are very useful, and would have to be implemented, too.\n\nWhat you'd have to do, if you chose to use diffutils stuff, is to \ntransform the main() of diff in diff_main(), use setjmp/longjmp to capture \nits exit()s, and make it use a proper allocator (if you want to avoid \nleaks upon aborts). You can see an example inside the diff/libgdiff \ndirectory of this packages:\n\nhttps://www.cvshome.org\nhttp://www.opencm.org\n\nIn that way, instead of executing \"diff -u ...\", you'd call diff_main() \nwith the proper args array. The CVS one (the other project seems dead, \nand they lifted the thing from CVS anyway) should be readily usable.\n\n\n- Davide\n"},{"id":"9262","messageId":"Pine.LNX.4.58.0509250941520.3308@g5.osdl.org","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509241526180.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-25T16:59:37Z","receivedAt":"2005-09-25T16:59:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 24 Sep 2005, Linus Torvalds wrote:\n>\n> Anyway, regardless, we could certainly make HEAD be a regular file \n> containing the name of the head instead.\n> \n> It probably wouldn't even require a whole lot of changes. HEAD already \n> ends up getting some special attention, since most of the things that look \n> for refs only look inside the .git/refs directory.\n\nThis patch does some of it. I decided not to special-case HEAD, but to \njust improve \"read_ref()\" a bit.\n\nChanging \"read_ref()\" was the trivial part - the bigger part that we had \nthree different implementations of it, and this patch is thus bigger just \nbecause it collapses them all into \"read_ref()\" and makes the calling \nconventions acceptable to all.\n\nNOTE! This makes \"symbolic refs\" usable in general, ie you can do\n\n\techo \"ref: refs/tags/v0.99.7\" > .git/refs/tags/LATEST\n\nand that essentially makes \"LATEST\" a symbolic ref that points to the \nv0.99.7 tag without using a filesystem symlink. But it does NOT mean that \nyou can replace the HEAD symlink with a file containing \"refs/tags/master\" \nyet: there are _other_ parts of git that depend on it being a symlink. \n\n(For the most core example, the \"write new head\" logic depends on just\nwriting to HEAD, and that symlink will automatically change that write to \nthe thing the HEAD _points_ to. That's the biggest one).\n\nI'll change those too to accept a regular file, if people agree this is \nworthwhile. In theory there are even UNIXes out there that don't support \nsymlinks, so maybe it's worth it. But maybe people dislike this.\n\nIn the meantime, you can test this out with\n\n\techo \"ref: HEAD\" > .git/TEST_HEAD\n\tgit-rev-parse HEAD TEST_HEAD master\n\nwhich - if your HEAD points to master - should print out the same SHA1\nthree times ;)\n\n\t\tLinus\n\n---\nSubject: Allow reading \"symbolic refs\" that point to other refs\n\nThis extends the ref reading to understand a \"symbolic ref\": a ref file \nthat starts with \"ref: \" and points to another ref file, and thus \nintroduces the notion of ref aliases.\n\nThis is in preparation of allowing HEAD to eventually not be a symlink, \nbut one of these symbolic refs instead.\n\nSigned-off-by: Linus Torvalds \n---\ndiff --git a/cache.h b/cache.h\n--- a/cache.h\n+++ b/cache.h\n@@ -227,6 +227,7 @@ extern int has_pack_index(const unsigned\n extern int get_sha1(const char *str, unsigned char *sha1);\n extern int get_sha1_hex(const char *hex, unsigned char *sha1);\n extern char *sha1_to_hex(const unsigned char *sha1);\t/* static buffer result! */\n+extern int read_ref(const char *filename, unsigned char *sha1);\n \n /* General helper functions */\n extern void usage(const char *err) NORETURN;\ndiff --git a/refs.c b/refs.c\n--- a/refs.c\n+++ b/refs.c\n@@ -2,17 +2,38 @@\n #include \"cache.h\"\n \n #include \n+#include \n \n-static int read_ref(const char *refname, unsigned char *sha1)\n+/* We allow \"recursive\" symbolic refs. Only within reason, though */\n+#define MAXDEPTH 5\n+\n+int read_ref(const char *filename, unsigned char *sha1)\n {\n-\tint ret = -1;\n-\tint fd = open(git_path(\"%s\", refname), O_RDONLY);\n+\tint depth = 0;\n+\tint ret = -1, fd;\n+\n+\twhile ((fd = open(filename, O_RDONLY)) >= 0) {\n+\t\tchar buffer[256];\n+\t\tint len = read(fd, buffer, sizeof(buffer)-1);\n \n-\tif (fd >= 0) {\n-\t\tchar buffer[60];\n-\t\tif (read(fd, buffer, sizeof(buffer)) >= 40)\n-\t\t\tret = get_sha1_hex(buffer, sha1);\n \t\tclose(fd);\n+\t\tif (len < 0)\n+\t\t\tbreak;\n+\n+\t\tbuffer[len] = 0;\n+\t\twhile (len && isspace(buffer[len-1]))\n+\t\t\tbuffer[--len] = 0;\n+\n+\t\tif (!strncmp(buffer, \"ref: \", 5)) {\n+\t\t\tif (depth > MAXDEPTH)\n+\t\t\t\tbreak;\n+\t\t\tdepth++;\n+\t\t\tfilename = git_path(\"%s\", buffer+5);\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (len >= 40)\n+\t\t\tret = get_sha1_hex(buffer, sha1);\n+\t\tbreak;\n \t}\n \treturn ret;\n }\n@@ -54,7 +75,7 @@ static int do_for_each_ref(const char *b\n \t\t\t\t\tbreak;\n \t\t\t\tcontinue;\n \t\t\t}\n-\t\t\tif (read_ref(path, sha1) < 0)\n+\t\t\tif (read_ref(git_path(\"%s\", path), sha1) < 0)\n \t\t\t\tcontinue;\n \t\t\tif (!has_sha1_file(sha1))\n \t\t\t\tcontinue;\n@@ -71,7 +92,7 @@ static int do_for_each_ref(const char *b\n int head_ref(int (*fn)(const char *path, const unsigned char *sha1))\n {\n \tunsigned char sha1[20];\n-\tif (!read_ref(\"HEAD\", sha1))\n+\tif (!read_ref(git_path(\"HEAD\"), sha1))\n \t\treturn fn(\"HEAD\", sha1);\n \treturn 0;\n }\n@@ -101,33 +122,14 @@ static char *ref_lock_file_name(const ch\n \treturn ret;\n }\n \n-static int read_ref_file(const char *filename, unsigned char *sha1) {\n-\tint fd = open(filename, O_RDONLY);\n-\tchar hex[41];\n-\tif (fd < 0) {\n-\t\treturn error(\"Couldn't open %s\\n\", filename);\n-\t}\n-\tif ((read(fd, hex, 41) < 41) ||\n-\t (hex[40] != '\\n') ||\n-\t get_sha1_hex(hex, sha1)) {\n-\t\terror(\"Couldn't read a hash from %s\\n\", filename);\n-\t\tclose(fd);\n-\t\treturn -1;\n-\t}\n-\tclose(fd);\n-\treturn 0;\n-}\n-\n int get_ref_sha1(const char *ref, unsigned char *sha1)\n {\n-\tchar *filename;\n-\tint retval;\n+\tconst char *filename;\n+\n \tif (check_ref_format(ref))\n \t\treturn -1;\n-\tfilename = ref_file_name(ref);\n-\tretval = read_ref_file(filename, sha1);\n-\tfree(filename);\n-\treturn retval;\n+\tfilename = git_path(\"refs/%s\", ref);\n+\treturn read_ref(filename, sha1);\n }\n \n static int lock_ref_file(const char *filename, const char *lock_filename,\n@@ -140,7 +142,7 @@ static int lock_ref_file(const char *fil\n \t\treturn error(\"Couldn't open lock file for %s: %s\",\n \t\t\t filename, strerror(errno));\n \t}\n-\tretval = read_ref_file(filename, current_sha1);\n+\tretval = read_ref(filename, current_sha1);\n \tif (old_sha1) {\n \t\tif (retval) {\n \t\t\tclose(fd);\ndiff --git a/sha1_name.c b/sha1_name.c\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -119,21 +119,6 @@ static int get_short_sha1(const char *na\n \treturn -1;\n }\n \n-static int get_sha1_file(const char *path, unsigned char *result)\n-{\n-\tchar buffer[60];\n-\tint fd = open(path, O_RDONLY);\n-\tint len;\n-\n-\tif (fd < 0)\n-\t\treturn -1;\n-\tlen = read(fd, buffer, sizeof(buffer));\n-\tclose(fd);\n-\tif (len < 40)\n-\t\treturn -1;\n-\treturn get_sha1_hex(buffer, result);\n-}\n-\n static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n {\n \tstatic const char *prefix[] = {\n@@ -150,7 +135,7 @@ static int get_sha1_basic(const char *st\n \n \tfor (p = prefix; *p; p++) {\n \t\tchar *pathname = git_path(\"%s/%.*s\", *p, len, str);\n-\t\tif (!get_sha1_file(pathname, sha1))\n+\t\tif (!read_ref(pathname, sha1))\n \t\t\treturn 0;\n \t}\n \n"},{"id":"9263","messageId":"Pine.LNX.4.58.0509250959540.3308@g5.osdl.org","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509250854570.22725@localhost.localdomain","subject":"Re: Implementing diff, was Re: git 0.99.7b doesn't build on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-25T17:00:58Z","receivedAt":"2005-09-25T17:00:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 25 Sep 2005, Davide Libenzi wrote:\n>\n> What you'd have to do, if you chose to use diffutils stuff, is to \n> transform the main() of diff in diff_main(), use setjmp/longjmp to capture \n> its exit()s, and make it use a proper allocator (if you want to avoid \n> leaks upon aborts).\n\nI'd love to use libxdiff instead since you say it can do it, but quite\nfrankly, the man-page didn't much help me. Do you have an example of how\nto generate a uni-diff with it? Something that mortal men can read and say \n\"oh\"?\n\n\t\tLinus\n"},{"id":"9270","messageId":"Pine.LNX.4.63.0509251205230.23415@localhost.localdomain","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509250959540.3308@g5.osdl.org","subject":"Re: Implementing diff, was Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-25T19:16:16Z","receivedAt":"2005-09-25T19:16:16Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Sun, 25 Sep 2005, Linus Torvalds wrote:\n\n> On Sun, 25 Sep 2005, Davide Libenzi wrote:\n>>\n>> What you'd have to do, if you chose to use diffutils stuff, is to\n>> transform the main() of diff in diff_main(), use setjmp/longjmp to capture\n>> its exit()s, and make it use a proper allocator (if you want to avoid\n>> leaks upon aborts).\n>\n> I'd love to use libxdiff instead since you say it can do it, but quite\n> frankly, the man-page didn't much help me. Do you have an example of how\n> to generate a uni-diff with it? Something that mortal men can read and say\n> \"oh\"?\n\nAhh, you looked at the docs. Don't do that ;) Take a look at the \ntest/xdiff_test.c for an example on how to use its most important APIs. \nThere is also a regression test (xregression) that create random files, \nrenadomly changes them, and then try that (A-B)+B=A and (B-A)+A=B (for \nboth text and binary). I'm dropping inline an example on how to text-diff ...\n\n\n\n- Davide\n\n\n\n#include \"xmacros.h\"\n#include \"xdiff.h\"\n\n#define XDLT_STD_BLKSIZE (1024 * 8)\n\nstatic int xdlt_load_mmfile(char const *fname, mmfile_t *mf, int binmode) {\n char cc;\n int fd;\n long size, bsize;\n char *blk;\n\n if (xdl_init_mmfile(mf, XDLT_STD_BLKSIZE, XDL_MMF_ATOMIC) < 0) {\n\n return -1;\n }\n if ((fd = open(fname, O_RDONLY)) == -1) {\n perror(fname);\n xdl_free_mmfile(mf);\n return -1;\n }\n if ((size = bsize = lseek(fd, 0, SEEK_END)) > 0 && !binmode) {\n if (lseek(fd, -1, SEEK_END) != (off_t) -1 &&\n read(fd, &cc, 1) && cc != '\\n')\n bsize++;\n }\n lseek(fd, 0, SEEK_SET);\n if (!(blk = (char *) xdl_mmfile_writeallocate(mf, bsize))) {\n xdl_free_mmfile(mf);\n close(fd);\n return -1;\n }\n if (read(fd, blk, (size_t) size) != (size_t) size) {\n perror(fname);\n xdl_free_mmfile(mf);\n close(fd);\n return -1;\n }\n close(fd);\n if (bsize > size)\n blk[size] = '\\n';\n return 0;\n}\n\nstatic int xdlt_outf(void *priv, mmbuffer_t *mb, int nbuf) {\n int i;\n\n for (i = 0; i < nbuf; i++)\n if (!fwrite(mb[i].ptr, mb[i].size, 1, (FILE *) priv))\n return -1;\n return 0;\n}\n\nstatic void *wrap_malloc(void *priv, unsigned int size) {\n\n return malloc(size);\n}\n\nstatic void wrap_free(void *priv, void *ptr) {\n\n free(ptr);\n}\n\nstatic void *wrap_realloc(void *priv, void *ptr, unsigned int size) {\n\n return realloc(ptr, size);\n}\n\nint sample_textdiff(char const *pre, char const *post, FILE *outf) {\n int error;\n memallocator_t malt;\n mmfile_t mf1, mf2;\n xpparam_t xpp;\n xdemitconf_t xecfg;\n xdemitcb_t ecb;\n\n malt.priv = NULL;\n malt.malloc = wrap_malloc;\n malt.free = wrap_free;\n malt.realloc = wrap_realloc;\n xdl_set_allocator(&malt);\n if (xdlt_load_mmfile(pre, &mf1, 0) < 0)\n return -1;\n if (xdlt_load_mmfile(post, &mf2, 0) < 0) {\n xdl_free_mmfile(&mf1);\n return -1;\n }\n xpp.flags = 0;\n xecfg.ctxlen = 3;\n ecb.priv = outf;\n ecb.outf = xdlt_outf;\n error = xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);\n xdl_free_mmfile(&mf2);\n xdl_free_mmfile(&mf1);\n\n return error;\n}\n"},{"id":"9293","messageId":"1o29so2d1zd0i$.1d0cf386vluxi.dlg@40tude.net","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509241540170.16554@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Giuseppe Bilotta","fromEmail":"bilotta78@hotpop.com","sentAt":"2005-09-25T19:59:42Z","receivedAt":"2005-09-25T19:59:42Z","isPatch":false,"sender":{"key":"bilotta78@hotpop.com","avatar":null},"body":"On Sat, 24 Sep 2005 15:41:27 -0700 (PDT), Davide Libenzi wrote:\n\n> On Sat, 24 Sep 2005, Linus Torvalds wrote:\n> \n>>\n>>\n>> On Sat, 24 Sep 2005, Davide Libenzi wrote:\n>>>\n>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp\n>>\n>> Don't you mean\n>>\n>> \thttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp\n>>\n>> rather?\n>>\n>> It mentions longhorn.\n> \n> Hah, didn't know this one. Requiring LongHorn is pretty strict though ;)\n\nHowever, it might be possible to use .lnk files, which would work on\nboth NTFS and FAT32, and even under Win9x.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n\n\"I weep for our generation\" -- Charlie Brown\n"},{"id":"9294","messageId":"7vwtl4jui4.fsf@assigned-by-dhcp.cox.net","threadId":"1925","inReplyTo":"1o29so2d1zd0i$.1d0cf386vluxi.dlg@40tude.net","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-26T04:57:55Z","receivedAt":"2005-09-26T04:57:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Giuseppe Bilotta writes:\n\n>> Hah, didn't know this one. Requiring LongHorn is pretty strict though ;)\n>\n> However, it might be possible to use .lnk files, which would work on\n> both NTFS and FAT32, and even under Win9x.\n\nPossibly, but it is a moot point now.\n\nWhen textual \"symbolic refs\" support becomes mature, we will use\nit on boxes without symbolic links to express .git/HEAD.\n"},{"id":"9295","messageId":"Pine.LNX.4.63.0509252203510.817@localhost.localdomain","threadId":"1925","inReplyTo":"1o29so2d1zd0i$.1d0cf386vluxi.dlg@40tude.net","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-26T05:05:29Z","receivedAt":"2005-09-26T05:05:29Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Sun, 25 Sep 2005, Giuseppe Bilotta wrote:\n\n> However, it might be possible to use .lnk files, which would work on\n> both NTFS and FAT32, and even under Win9x.\n\nThe .lnk files are a shell thing, not an OS one. Try to open()+read() a \n.lnk file and look at what you get ...\n\n\n- Davide\n"},{"id":"9297","messageId":"11uvm3it7p3tu.1wbs1o8fvs02r.dlg@40tude.net","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509252203510.817@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Giuseppe Bilotta","fromEmail":"bilotta78@hotpop.com","sentAt":"2005-09-26T11:00:18Z","receivedAt":"2005-09-26T11:00:18Z","isPatch":false,"sender":{"key":"bilotta78@hotpop.com","avatar":null},"body":"On Sun, 25 Sep 2005 22:05:29 -0700 (PDT), Davide Libenzi wrote:\n\n> On Sun, 25 Sep 2005, Giuseppe Bilotta wrote:\n> \n>> However, it might be possible to use .lnk files, which would work on\n>> both NTFS and FAT32, and even under Win9x.\n> \n> The .lnk files are a shell thing, not an OS one. Try to open()+read() a \n> .lnk file and look at what you get ...\n\nWell, sure. I wasn't thinking about just substituting .lnk files for\nsymlinks, but that's the closest thing you can get on Windows,\ncurrently, so maybe supporting this kind of thing would be the best\napproach.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n\n[W]hat country can preserve its liberties, if its rulers are not\nwarned from time to time that [the] people preserve the spirit of\nresistance? Let them take arms...The tree of liberty must be\nrefreshed from time to time, with the blood of patriots and\ntyrants.\n\t-- Thomas Jefferson, letter to Col. William S. Smith, 1787\n"},{"id":"9317","messageId":"1127763214.5735.25.camel@cashmere.sps.mot.com","threadId":"1925","inReplyTo":"Pine.LNX.4.58.0509241526180.3308@g5.osdl.org","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-09-26T19:33:34Z","receivedAt":"2005-09-26T19:33:34Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Sat, 2005-09-24 at 17:27, Linus Torvalds wrote:\n> On Sat, 24 Sep 2005, Linus Torvalds wrote:\n> > \n> > It mentions longhorn.\n> \n> Anyway, regardless, we could certainly make HEAD be a regular file \n> containing the name of the head instead.\n\nI cleverly removed a branch this morning (intentionally),\nbut what I failed to realize was that it was also the\ncurrent HEAD. The next series of command were oddly\ncryptic, only telling me the git-read-tree usage message.\nNot a clue in the world why, of course. After poking\naround, reading some scripts and all, I discovered that\nI had a dangling .git/HEAD symlink still point to my\nremoved branch.\n\nWould it be worthwhile for me to re-discover this\nWonky Failure (Hi Linus! :-) and try to write it up\nsomewhere or dream up a better error message patch?\n\nThanks,\njdl\n"},{"id":"9321","messageId":"7v3bnrinoa.fsf@assigned-by-dhcp.cox.net","threadId":"1925","inReplyTo":"1127763214.5735.25.camel@cashmere.sps.mot.com","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-26T20:23:01Z","receivedAt":"2005-09-26T20:23:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n> Would it be worthwhile for me to re-discover this\n> Wonky Failure (Hi Linus! :-) and try to write it up\n> somewhere or dream up a better error message patch?\n\nThanks.\n"},{"id":"9332","messageId":"43386E0A.6010607@zytor.com","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509252203510.817@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-26T21:54:18Z","receivedAt":"2005-09-26T21:54:18Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Davide Libenzi wrote:\n> On Sun, 25 Sep 2005, Giuseppe Bilotta wrote:\n> \n>> However, it might be possible to use .lnk files, which would work on\n>> both NTFS and FAT32, and even under Win9x.\n> \n> \n> The .lnk files are a shell thing, not an OS one. Try to open()+read() a \n> .lnk file and look at what you get ...\n> \n\nExcept that Cygwin uses them transparently, so if you do open() and \nread() under Cygwin they work as expected.\n\n\t-hpa\n"},{"id":"9334","messageId":"Pine.LNX.4.63.0509261502080.1716@localhost.localdomain","threadId":"1925","inReplyTo":"43386E0A.6010607@zytor.com","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-09-26T22:03:40Z","receivedAt":"2005-09-26T22:03:40Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Mon, 26 Sep 2005, H. Peter Anvin wrote:\n\n> Davide Libenzi wrote:\n>> On Sun, 25 Sep 2005, Giuseppe Bilotta wrote:\n>> \n>>> However, it might be possible to use .lnk files, which would work on\n>>> both NTFS and FAT32, and even under Win9x.\n>> \n>> \n>> The .lnk files are a shell thing, not an OS one. Try to open()+read() a \n>> .lnk file and look at what you get ...\n>> \n>\n> Except that Cygwin uses them transparently, so if you do open() and read() \n> under Cygwin they work as expected.\n\nWith Cygwin you don't even need .lnk files, since it already supports all \nthe Unix symlinks APIs/cmds. The discussion born thinking about a native \nWin32 interface, w/out the Cygwin crud in it.\n\n\n- Davide\n"},{"id":"9338","messageId":"433872F5.5060807@zytor.com","threadId":"1925","inReplyTo":"Pine.LNX.4.63.0509261502080.1716@localhost.localdomain","subject":"Re: git 0.99.7b doesn't build on Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-26T22:15:17Z","receivedAt":"2005-09-26T22:15:17Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Davide Libenzi wrote:\n>>\n>> Except that Cygwin uses them transparently, so if you do open() and \n>> read() under Cygwin they work as expected.\n> \n> With Cygwin you don't even need .lnk files, since it already supports \n> all the Unix symlinks APIs/cmds. The discussion born thinking about a \n> native Win32 interface, w/out the Cygwin crud in it.\n> \n\nCygwin symbolic links are implemented as .lnk files on the underlying \nfilesystem was my point.\n\n\t-hpaa\n"}]}