{"thread":{"id":"1969","subject":"First cut at git port to Cygwin","startedAt":"2005-09-29T00:53:36Z","lastAt":"2005-10-10T20:52:27Z","messageCount":62,"participants":["H. Peter Anvin","Junio C Hamano","Martin Langhoff","Johannes Schindelin","Alex Riesen","Christopher Faylor","Jonas Fonseca","Davide Libenzi","Linus Torvalds","Chuck Lever","Elfyn McBratney","Matthias Urlichs","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9445","messageId":"433B3B10.5050407@zytor.com","threadId":"1969","inReplyTo":null,"subject":"First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-29T00:53:36Z","receivedAt":"2005-09-29T00:53:36Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"I have made a first cut at a git port to Cygwin. It looks like the \n\"git-diff-tree -p\" problem has been resolved independently, or at least \nI can't reproduce it on a fresh Cygwin install (running on XP Home), but \nI have added support for running without the IPv6 and the getaddrinfo() API.\n\nThere are still funnies. In particular, Cygwin and Samba handle \nsymlinks differently, so you can't trivially share a repository via \nSamba. Linus' \"symbolic refs\" changes should eventually take care of that.\n\nAnother funny which I haven't been able to figure out yet is that 'gitk' \nscrunches all its output up into a few pixels at the top of the window. \n If I maximize the window, I can manually resize most of the panes and \nthe output looks correct, but the highlighted text in the top panes show \nup in black on a really really dark blue background and is thus illegible.\n\nI have set up a git-on-Cygwin temporary tree at:\n\nhttp://www.kernel.org/pub/scm/git/git-cygwin.git\n\n\t-hpa\n"},{"id":"9450","messageId":"7v64skpkbb.fsf@assigned-by-dhcp.cox.net","threadId":"1969","inReplyTo":"433B3B10.5050407@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-29T04:30:32Z","receivedAt":"2005-09-29T04:30:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> There are still funnies. In particular, Cygwin and Samba handle \n> symlinks differently, so you can't trivially share a repository via \n> Samba. Linus' \"symbolic refs\" changes should eventually take care of that.\n\nI just sent out \"The other side of Linus' symbolic refs\" patch,\nsaying that Cygwin capable of doing symlink would probably made\nit irrelevant. But it may not be a waste after all, considering\nwhat you said above.\n"},{"id":"9453","messageId":"46a038f905092821462d08f86a@mail.gmail.com","threadId":"1969","inReplyTo":"433B3B10.5050407@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-09-29T04:46:51Z","receivedAt":"2005-09-29T04:46:51Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/29/05, H. Peter Anvin wrote:\n> Another funny which I haven't been able to figure out yet is that 'gitk'\n> scrunches all its output up into a few pixels at the top of the window.\n> If I maximize the window, I can manually resize most of the panes and\n> the output looks correct\n\nThis is visible on OSX too, and someone's mentioned it's a Tk oddity\nwith rootless X. Does it do the same if you run X with a root window?\n\n> I have set up a git-on-Cygwin temporary tree at:\n>\n> http://www.kernel.org/pub/scm/git/git-cygwin.git\n\nGetting a 404 on that. Doesn't show up on gitweb either. I guess I\nhave to wait...\n\nIs there a way to get gitweb to \"compare\" branches using git-cherry? I\noften look at branches via git-web and it's impossible to tell what\nmakes them unique...\n\ncheers,\n\n\nmartin\n"},{"id":"9455","messageId":"433B767E.7050704@zytor.com","threadId":"1969","inReplyTo":"7v64skpkbb.fsf@assigned-by-dhcp.cox.net","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-29T05:07:10Z","receivedAt":"2005-09-29T05:07:10Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n> \n>>There are still funnies. In particular, Cygwin and Samba handle \n>>symlinks differently, so you can't trivially share a repository via \n>>Samba. Linus' \"symbolic refs\" changes should eventually take care of that.\n> \n> \n> I just sent out \"The other side of Linus' symbolic refs\" patch,\n> saying that Cygwin capable of doing symlink would probably made\n> it irrelevant. But it may not be a waste after all, considering\n> what you said above.\n> \n\nAfter looking at it some more, what Samba does when talking to a host \nthat doesn't support Unix extensions is that it simply resolves the \nsymlink, in effect turning it into a hard link. That might be all git \nneeds. The reverse still doesn't work, though.\n\n\t-hpa\n"},{"id":"9457","messageId":"7vd5mso3ql.fsf@assigned-by-dhcp.cox.net","threadId":"1969","inReplyTo":"46a038f905092821462d08f86a@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-29T05:13:54Z","receivedAt":"2005-09-29T05:13:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff writes:\n\n> Is there a way to get gitweb to \"compare\" branches using git-cherry? I\n> often look at branches via git-web and it's impossible to tell what\n> makes them unique...\n\nNow that you mention it, I felt that too. Maybe git-show-branch\noutput could help somehow?\n"},{"id":"9460","messageId":"433B877B.6010004@zytor.com","threadId":"1969","inReplyTo":"46a038f905092821462d08f86a@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-29T06:19:39Z","receivedAt":"2005-09-29T06:19:39Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Martin Langhoff wrote:\n> \n>>I have set up a git-on-Cygwin temporary tree at:\n>>\n>>http://www.kernel.org/pub/scm/git/git-cygwin.git\n> \n> Getting a 404 on that. Doesn't show up on gitweb either. I guess I\n> have to wait...\n> \n\nWell, it's up there now.\n\n\t-hpa\n"},{"id":"9470","messageId":"Pine.LNX.4.63.0509291043580.20717@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1969","inReplyTo":"433B3B10.5050407@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-09-29T08:46:15Z","receivedAt":"2005-09-29T08:46:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Sep 2005, H. Peter Anvin wrote:\n\n> Another funny which I haven't been able to figure out yet is that 'gitk'\n> scrunches all its output up into a few pixels at the top of the window.\n\nSee my mail about rootless X11. I went about working around that \nparticular Tk bug by specifying the dimensions of the panes explicitely. \nHowever, I was not especially happy with my workaround, since it did not \nreproduce the layout exactly after a restart. Maybe you can figure it out \nhow to do that.\n\nCiao,\nDscho\n"},{"id":"9483","messageId":"433C122B.3050509@zytor.com","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0509291043580.20717@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-29T16:11:23Z","receivedAt":"2005-09-29T16:11:23Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 28 Sep 2005, H. Peter Anvin wrote:\n> \n>>Another funny which I haven't been able to figure out yet is that 'gitk'\n>>scrunches all its output up into a few pixels at the top of the window.\n> \n> See my mail about rootless X11. I went about working around that \n> particular Tk bug by specifying the dimensions of the panes explicitely. \n> However, I was not especially happy with my workaround, since it did not \n> reproduce the layout exactly after a restart. Maybe you can figure it out \n> how to do that.\n> \n\nUnlikely, since I'm a complete Tcl/Tk illiterate.\n\n\t-hpa\n"},{"id":"9486","messageId":"433C237A.20401@zytor.com","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0509291043580.20717@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-29T17:25:14Z","receivedAt":"2005-09-29T17:25:14Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 28 Sep 2005, H. Peter Anvin wrote:\n> \n>>Another funny which I haven't been able to figure out yet is that 'gitk'\n>>scrunches all its output up into a few pixels at the top of the window.\n> \n> See my mail about rootless X11. I went about working around that \n> particular Tk bug by specifying the dimensions of the panes explicitely. \n> However, I was not especially happy with my workaround, since it did not \n> reproduce the layout exactly after a restart. Maybe you can figure it out \n> how to do that.\n> \n\nIt looks like this isn't a rootless *X* thing; it looks like the wish \nthat is included with Cygwin actually opens native Win32 windows; even \nwhen run from inside a rooted X session it still opens an external \nwindow. I also tried using the wish from the latest ActiveState \ndistribution; it exhibits the same problem although with slightly \ndifferent geometries.\n\n\t-hpa\n"},{"id":"9544","messageId":"7v4q826ffy.fsf@assigned-by-dhcp.cox.net","threadId":"1969","inReplyTo":"433B3B10.5050407@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-30T10:02:57Z","receivedAt":"2005-09-30T10:02:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> I have set up a git-on-Cygwin temporary tree at:\n>\n> http://www.kernel.org/pub/scm/git/git-cygwin.git\n\n: siamese; git clone http://kernel.org/pub/scm/git/git-cygwin.git/ git-cygwin\ndefaulting to local storage area\nCannot get remote repository information.\nPerhaps git-update-server-info needs to be run there?\n\nCould you do update-server-info there, please?\n\nhera$ cd /pub/scm/git/git-cygwin.git\nhera$ GIT_DIR=. git-update-server-info\n\n\n\nKnowing nothing about Cygwin environment, here are some\ncomments.\n\n +# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().\n\nThis part probably is applicable outside Cygwin. At some point,\ncan we have it in the mainline please?\n\n # The ones that do not have to link with lcrypto nor lz.\n SIMPLE_PROGRAMS = \\\n -\tgit-get-tar-commit-id git-mailinfo git-mailsplit git-stripspace \\\n -\tgit-daemon git-var\n +\tgit-get-tar-commit-id$(X) git-mailinfo$(X) git-mailsplit$(X) \\\n +\tgit-stripspace$(X) git-var$(X) git-daemon$(X)\n \nI have seen these $(X) in other programs' ports and found them\nquite distasteful. Since I do not have immediate suggestions\nfor improvements, I do not have rights to complain, though.\n\nSpelling it $X is a bit less distracting but not that much\nbetter. Maybe \"SIMPLE_PROGRAM_NAMES = git-foo git-bar\" and\n\"SIMPLE_PROGRAMS = $(patsubst %,%$X,$(SIMPLE_PROGRAM_NAMES))\"...\nbut that would not help bits like this:\n\n -\tPROGRAMS += git-http-fetch\n +\tPROGRAMS += git-http-fetch$(X)\n\nor this: \n\n -git-%: %.o $(LIB_FILE)\n +git-%$(X): %.o $(LIB_FILE)\n\n... so I'd shut up about this part.\n\n diff --git a/daemon.c b/daemon.c\n --- a/daemon.c\n +++ b/daemon.c\n @@ -1,9 +1,11 @@\n #include \"cache.h\"\n #include \"pkt-line.h\"\n +#include \n\nWhy? I do not see any use of alloca in the added code...\n\n +#include \n\nIs poll preferrable over select in general? Some may have only\nselect available and others may have only poll available,\nperhaps? In any case, this is probably relevant to wider\naudience than just Cygwin; please give it to mainline at some\npoint, perhaps conditionally allowing either/both.\n\n +\t*socklist_p = malloc(sizeof(int));\n +\tpfd = calloc(socknum, sizeof(struct pollfd));\n\nPlease use xmalloc and xcalloc just for consistency.\n\n test -x $path/git-$cmd && exec $path/git-$cmd \"$@\" ;;\n +\n +\t# In case we're running on Cygwin...\n +\ttest -x $path/git-$cmd.exe && exec $path/git-$cmd.exe \"$@\" ;;\n esac\n \nHmph, I think you forgot to drop double semicolon there.\n\nThe git.sh script is munged by Makefile so presumably we could\nfix this part up there, like:\n\n git: git.sh Makefile\n rm -f $@+ $@\n sed -e '1s|#!.*/sh|#!$(SHELL_PATH)|' \\\n -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n -e 's/@@X@@/$X/g' <$@.sh >$@+\n chmod +x $@+\n mv $@+ $@\n\nAnd then (a patch on top of your \"master\"):\n\ndiff --git a/git.sh b/git.sh\n--- a/git.sh\n+++ b/git.sh\n@@ -12,10 +12,14 @@ case \"$#\" in\n \t\texit 0 ;;\n \tesac\n \n-\ttest -x $path/git-$cmd && exec $path/git-$cmd \"$@\" ;;\n+\ttest -x $path/git-$cmd && exec $path/git-$cmd \"$@\"\n \n-\t# In case we're running on Cygwin...\n-\ttest -x $path/git-$cmd.exe && exec $path/git-$cmd.exe \"$@\" ;;\n+\tcase '@@X@@' in\n+\t'')\n+\t\t;;\n+\t*)\n+\t\ttest -x $path/git-$cmd@@X@@ && exec $path/git-$cmd@@X@@ \"$@\" ;;\n+\tesac\t\t\n esac\n \n echo \"Usage: git COMMAND [OPTIONS] [TARGET]\"\n"},{"id":"9560","messageId":"433D6F62.3030906@zytor.com","threadId":"1969","inReplyTo":"7v4q826ffy.fsf@assigned-by-dhcp.cox.net","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-30T17:01:22Z","receivedAt":"2005-09-30T17:01:22Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> Could you do update-server-info there, please?\n> \n\nDone...\n\n> \n> Knowing nothing about Cygwin environment, here are some\n> comments.\n> \n> +# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().\n> \n> This part probably is applicable outside Cygwin. At some point,\n> can we have it in the mainline please?\n> \n\nWell, I would hope that all the changes could eventually be merged.\n\n> # The ones that do not have to link with lcrypto nor lz.\n> SIMPLE_PROGRAMS = \\\n> -\tgit-get-tar-commit-id git-mailinfo git-mailsplit git-stripspace \\\n> -\tgit-daemon git-var\n> +\tgit-get-tar-commit-id$(X) git-mailinfo$(X) git-mailsplit$(X) \\\n> +\tgit-stripspace$(X) git-var$(X) git-daemon$(X)\n> \n> I have seen these $(X) in other programs' ports and found them\n> quite distasteful. Since I not have immediate suggestions\n> for improvements, I do not have rights to complain, though.\n> \n> Spelling it $X is a bit less distracting but not that much\n> better. Maybe \"SIMPLE_PROGRAM_NAMES = git-foo git-bar\" and\n> \"SIMPLE_PROGRAMS = $(patsubst %,%$X,$(SIMPLE_PROGRAM_NAMES))\"...\n> but that would not help bits like this:\n> \n> -\tPROGRAMS += git-http-fetch\n> +\tPROGRAMS += git-http-fetch$(X)\n> \n> or this: \n> \n> -git-%: %.o $(LIB_FILE)\n> +git-%$(X): %.o $(LIB_FILE)\n> \n> ... so I'd shut up about this part.\n\nMy first cut had PROGRAMS_X and SIMPLE_PROGRAMS_X being patsubst of the \noriginal versions, but in the end I decided it was even uglier, because \nthese patterns were needed elsewhere. I'll change them to $X except \nwhere the parens are needed.\n\n> diff --git a/daemon.c b/daemon.c\n> --- a/daemon.c\n> +++ b/daemon.c\n> @@ -1,9 +1,11 @@\n> #include \"cache.h\"\n> #include \"pkt-line.h\"\n> +#include \n> \n> Why? I do not see any use of alloca in the added code...\n\nI originally used alloca() before changing my mind and using calloc(); I \nthink there might be platforms without alloca out there.\n\n> +#include \n> \n> Is poll preferrable over select in general? Some may have only\n> select available and others may have only poll available,\n> perhaps? In any case, this is probably relevant to wider\n> audience than just Cygwin; please give it to mainline at some\n> point, perhaps conditionally allowing either/both.\n\nThe main reason I switched to poll() is that I believe all platforms \nthat are even remotely relevant have both these days, and forming a poll \nlist is so much cleaner than forming a select set. What makes forming a \nselect set even remotely bearable is the invalid assumption that the \nnumber of file descriptors is bounded at compile time and therefore that \nfdset_t can be statically allocated. We've had problems in the past \nwith that assumption on Linux, and I've tried to avoid select since then.\n\n> +\t*socklist_p = malloc(sizeof(int));\n> +\tpfd = calloc(socknum, sizeof(struct pollfd));\n> \n> Please use xmalloc and xcalloc just for consistency.\n\nCheck.\n\n> test -x $path/git-$cmd && exec $path/git-$cmd \"$@\" ;;\n> +\n> +\t# In case we're running on Cygwin...\n> +\ttest -x $path/git-$cmd.exe && exec $path/git-$cmd.exe \"$@\" ;;\n> esac\n> \n> Hmph, I think you forgot to drop double semicolon there.\n\nD'oh!\n\n> The git.sh script is munged by Makefile so presumably we could\n> fix this part up there, like:\n> \n> git: git.sh Makefile\n> rm -f $@+ $@\n> sed -e '1s|#!.*/sh|#!$(SHELL_PATH)|' \\\n> -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n> -e 's/@@X@@/$X/g' <$@.sh >$@+\n> chmod +x $@+\n> mv $@+ $@\n> \n> And then (a patch on top of your \"master\"):\n> \n> diff --git a/git.sh b/git.sh\n> --- a/git.sh\n> +++ b/git.sh\n> @@ -12,10 +12,14 @@ case \"$#\" in\n> \t\texit 0 ;;\n> \tesac\n> \n> -\ttest -x $path/git-$cmd && exec $path/git-$cmd \"$@\" ;;\n> +\ttest -x $path/git-$cmd && exec $path/git-$cmd \"$@\"\n> \n> -\t# In case we're running on Cygwin...\n> -\ttest -x $path/git-$cmd.exe && exec $path/git-$cmd.exe \"$@\" ;;\n> +\tcase '@@X@@' in\n> +\t'')\n> +\t\t;;\n> +\t*)\n> +\t\ttest -x $path/git-$cmd@@X@@ && exec $path/git-$cmd@@X@@ \"$@\" ;;\n> +\tesac\t\t\n> esac\n> \n> echo \"Usage: git COMMAND [OPTIONS] [TARGET]\"\n\nThat wouldn't work, because the shell scripts don't get the .exe \nextension. However, I can figure out something equivalent.\n\n\t-hpa\n"},{"id":"9565","messageId":"433D8D1A.9010904@zytor.com","threadId":"1969","inReplyTo":"433D6F62.3030906@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-30T19:08:10Z","receivedAt":"2005-09-30T19:08:10Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Okay, I have updated the git-cygwin repository with the changes \nproposed, and they seem to work.\n\n\t-hpa\n"},{"id":"9668","messageId":"81b0412b0510040531m441ca759k6d1f3fbf0cd248ce@mail.gmail.com","threadId":"1969","inReplyTo":"433B3B10.5050407@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-04T12:31:40Z","receivedAt":"2005-10-04T12:31:40Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 9/29/05, H. Peter Anvin wrote:\n> I have made a first cut at a git port to Cygwin. It looks like the\n> \"git-diff-tree -p\" problem has been resolved independently, or at least\n> I can't reproduce it on a fresh Cygwin install (running on XP Home), but\n> I have added support for running without the IPv6 and the getaddrinfo() API.\n>\n> There are still funnies. In particular, Cygwin and Samba handle\n> symlinks differently, so you can't trivially share a repository via\n> Samba. Linus' \"symbolic refs\" changes should eventually take care of that.\n\nI noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the\ntarget and returns an error (probably EPERM, but I have reasons not to trust\nstrerror on that thing).\nThe repository was on FAT.\nTaking \"rename(2)\" from cygwin's libiberty solved this (they unlink if link(2)\nreturns EEXIST).\n\nPS: Does broken rename(2) qualify a system \"not worthy to support\"?\n"},{"id":"9670","messageId":"81b0412b0510040606n41a8bec6o24b47d65ff1c050b@mail.gmail.com","threadId":"1969","inReplyTo":"81b0412b0510040531m441ca759k6d1f3fbf0cd248ce@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-04T13:06:26Z","receivedAt":"2005-10-04T13:06:26Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 10/4/05, Alex Riesen wrote:\n> On 9/29/05, H. Peter Anvin wrote:\n> > I have made a first cut at a git port to Cygwin. It looks like the\n> > \"git-diff-tree -p\" problem has been resolved independently, or at least\n> > I can't reproduce it on a fresh Cygwin install (running on XP Home), but\n> > I have added support for running without the IPv6 and the getaddrinfo() API.\n> >\n> > There are still funnies. In particular, Cygwin and Samba handle\n> > symlinks differently, so you can't trivially share a repository via\n> > Samba. Linus' \"symbolic refs\" changes should eventually take care of that.\n>\n> I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the\n> target and returns an error (probably EPERM, but I have reasons not to trust\n> strerror on that thing).\n> The repository was on FAT.\n> Taking \"rename(2)\" from cygwin's libiberty solved this (they unlink if link(2)\n> returns EEXIST).\n\nI think I have to clarify: I copied the function (like in strcasestr\ncase) into compat/\n"},{"id":"9671","messageId":"43428C65.3040205@zytor.com","threadId":"1969","inReplyTo":"81b0412b0510040531m441ca759k6d1f3fbf0cd248ce@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-04T14:06:29Z","receivedAt":"2005-10-04T14:06:29Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Alex Riesen wrote:\n> \n> I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the\n> target and returns an error (probably EPERM, but I have reasons not to trust\n> strerror on that thing).\n> The repository was on FAT.\n> Taking \"rename(2)\" from cygwin's libiberty solved this (they unlink if link(2)\n> returns EEXIST).\n> \n> PS: Does broken rename(2) qualify a system \"not worthy to support\"?\n\nIn this case a better way would be to just add -liberty to all link \nlines if necessary, but I would expect the core cygwin code to do this.\n\n\t-hpa\n"},{"id":"9674","messageId":"434299DB.7020805@zytor.com","threadId":"1969","inReplyTo":"81b0412b0510040531m441ca759k6d1f3fbf0cd248ce@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-04T15:03:55Z","receivedAt":"2005-10-04T15:03:55Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Alex Riesen wrote:\n> \n> I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the\n> target and returns an error (probably EPERM, but I have reasons not to trust\n> strerror on that thing).\n> The repository was on FAT.\n> Taking \"rename(2)\" from cygwin's libiberty solved this (they unlink if link(2)\n> returns EEXIST).\n> \n> PS: Does broken rename(2) qualify a system \"not worthy to support\"?\n\nI just tried this with Cygwin 1.5.18-1 and didn't have any such \nproblems. I tried it on NTFS, FAT and Samba, using WinXP.\n\n\t-hpa\n"},{"id":"9690","messageId":"20051005031547.GC1393@trixie.casa.cgf.cx","threadId":"1969","inReplyTo":"43428C65.3040205@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2005-10-05T03:15:47Z","receivedAt":"2005-10-05T03:15:47Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Tue, Oct 04, 2005 at 07:06:29AM -0700, H. Peter Anvin wrote:\n>Alex Riesen wrote:\n>>\n>>I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove \n>>the\n>>target and returns an error (probably EPERM, but I have reasons not to \n>>trust\n>>strerror on that thing).\n>>The repository was on FAT.\n>>Taking \"rename(2)\" from cygwin's libiberty solved this (they unlink if \n>>link(2)\n>>returns EEXIST).\n>>\n>>PS: Does broken rename(2) qualify a system \"not worthy to support\"?\n>\n>In this case a better way would be to just add -liberty to all link \n>lines if necessary, but I would expect the core cygwin code to do this.\n\nAFAIK, cygwin has a working rename(). Many packages rely on it.\n\nIf rename() is not working then a bug report with a test case would be\nappreciated.\n--\nChristopher Faylor\t\t\tspammer? ->\taaaspam@sourceware.org\nCygwin Co-Project Leader\t\t\t\taaaspam@duffek.com\nTimeSys, Inc.\n"},{"id":"9691","messageId":"20051005031642.GD1393@trixie.casa.cgf.cx","threadId":"1969","inReplyTo":"434299DB.7020805@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2005-10-05T03:16:42Z","receivedAt":"2005-10-05T03:16:42Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Tue, Oct 04, 2005 at 08:03:55AM -0700, H. Peter Anvin wrote:\n>Alex Riesen wrote:\n>>\n>>I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove \n>>the\n>>target and returns an error (probably EPERM, but I have reasons not to \n>>trust\n>>strerror on that thing).\n>>The repository was on FAT.\n>>Taking \"rename(2)\" from cygwin's libiberty solved this (they unlink if \n>>link(2)\n>>returns EEXIST).\n>>\n>>PS: Does broken rename(2) qualify a system \"not worthy to support\"?\n>\n>I just tried this with Cygwin 1.5.18-1 and didn't have any such \n>problems. I tried it on NTFS, FAT and Samba, using WinXP.\n\nThat's a relief. Btw, AFAIK, strerror is working correctly under\nCygwin also.\n--\nChristopher Faylor\t\t\tspammer? ->\taaaspam@sourceware.org\nCygwin Co-Project Leader\t\t\t\taaaspam@duffek.com\nTimeSys, Inc.\n"},{"id":"9693","messageId":"434363C2.2040501@zytor.com","threadId":"1969","inReplyTo":"20051005031642.GD1393@trixie.casa.cgf.cx","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-05T05:25:22Z","receivedAt":"2005-10-05T05:25:22Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Christopher Faylor wrote:\n> That's a relief. Btw, AFAIK, strerror is working correctly under\n> Cygwin also.\n\nNow if we can only figure out why gitk is messed up...\n\n\t-hpa\n"},{"id":"9697","messageId":"81b0412b0510050424h21fc06bav7677911f52b38426@mail.gmail.com","threadId":"1969","inReplyTo":"434299DB.7020805@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-05T11:24:40Z","receivedAt":"2005-10-05T11:24:40Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 10/4/05, H. Peter Anvin wrote:\n> > I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the\n> > target and returns an error (probably EPERM, but I have reasons not to trust\n> > strerror on that thing).\n> > The repository was on FAT.\n> > Taking \"rename(2)\" from cygwin's libiberty solved this (they unlink if link(2)\n> > returns EEXIST).\n> >\n> > PS: Does broken rename(2) qualify a system \"not worthy to support\"?\n>\n> I just tried this with Cygwin 1.5.18-1 and didn't have any such\n> problems. I tried it on NTFS, FAT and Samba, using WinXP.\n\nIt's on Win2k, there was multiple cygwin installations in path, the other one\nsupposedly is 1.5.5 (it's from QNX Momentics installation).\nI had that old \"cygwin1.dll\" renamed into \"cygwin1.dll-disabled\" long\nago, though...\nI can't reproduce this out of GIT context, and the error is not\nreproducable after\nI removed the other cygwin installation out of PATH.\nAnyway, sorry, I should have tried this before posting.\n"},{"id":"9699","messageId":"20051005131631.GA9442@diku.dk","threadId":"1969","inReplyTo":"433B3B10.5050407@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2005-10-05T13:16:31Z","receivedAt":"2005-10-05T13:16:31Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"I have a few things I experienced with the merged cygwin stuff. Sorry I\nhaven't investigated it further, but there should be enough for a few\nfixes.\n\nWhen I ...\n\n user@machine /usr/local/dev/git/git\n $ make prefix=/usr/local install\n install -d -m755 /usr/local/bin\n install git-apply.exe [...]\n sh ./cmd-rename.sh /usr/local/bin\n ln: creating symbolic link `/usr/local/bin/git-http-pull.exe' to `git-http-fetch.exe': File exists\n make: *** [install] Error 1\n\nCan be fixed by the patch below. I don't know if it would be cleaner to\npass cmd-rename.sh \"$X\" as a second argument from the Makefile.\n\n--- cmd-rename.sh\t2005-10-05 14:42:00.000000000 +0200\n+++ cmd-rename.sh-orig\t2005-10-05 14:43:48.000000000 +0200\n@@ -3,7 +3,7 @@\n test -d \"$d\" || exit\n while read old new\n do\n-\trm -f \"$d/$old\" \"$d/$old.exe\" \n+\trm -f \"$d/$old\"\n \tif test -f \"$d/$new\"\n \tthen\n \t\tln -s \"$new\" \"$d/$old\" || exit\n\n\nSome other obscurities ...\n\n user@machine /usr/local/dev/git/git\n $ git-log\n fatal: Not a git repository\n\n user@machine /usr/local/dev/git/git\n $ GIT_DIR=.git git-log | wc -l\n 26094\n\nand I cannot rebuild the index file with git-reset. First time I run it\nit creates the index.lock file and errors out when writing. The second\ntime it errors out because the lock file was not removed in the first\ncase.\n\n user@machine /usr/local/dev/git/git\n $ GIT_DIR=.git git-reset\n fatal: unable to write new index file\n \n user@machine /usr/local/dev/git/git\n $ GIT_DIR=.git git-reset\n fatal: unable to create new cachefile\n \n user@machine /usr/local/dev/git/git\n $ uname -a\n CYGWIN_NT-5.1 antimatter 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin\n\n-- \nJonas Fonseca\n"},{"id":"9701","messageId":"Pine.LNX.4.63.0510051556320.14244@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"1969","inReplyTo":"20051005131631.GA9442@diku.dk","subject":"Re: First cut at git port to Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-05T13:58:22Z","receivedAt":"2005-10-05T13:58:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 5 Oct 2005, Jonas Fonseca wrote:\n\n> user@machine /usr/local/dev/git/git\n> $ git-log\n> fatal: Not a git repository\n> \n> user@machine /usr/local/dev/git/git\n> $ GIT_DIR=.git git-log | wc -l\n> 26094\n\nThat could have its cause in your .git/HEAD being no symlink. That happens \nwhen rsync´ing the .git directory.\n\nThe other errors could also stem from the fact that quite a few places \nexpect HEAD to be a symlink.\n\nCiao,\nDscho\n"},{"id":"9705","messageId":"81b0412b0510050846l2258775co117bada2d2b5a1ad@mail.gmail.com","threadId":"1969","inReplyTo":"81b0412b0510050424h21fc06bav7677911f52b38426@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-05T15:46:08Z","receivedAt":"2005-10-05T15:46:08Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 10/5/05, Alex Riesen wrote:\n> On 10/4/05, H. Peter Anvin wrote:\n> > > I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the\n> > > target and returns an error (probably EPERM, but I have reasons not to trust\n> > > strerror on that thing).\n> > > The repository was on FAT.\n> > > Taking \"rename(2)\" from cygwin's libiberty solved this (they unlink if link(2)\n> > > returns EEXIST).\n> > >\n> > > PS: Does broken rename(2) qualify a system \"not worthy to support\"?\n> >\n> > I just tried this with Cygwin 1.5.18-1 and didn't have any such\n> > problems. I tried it on NTFS, FAT and Samba, using WinXP.\n>\n> It's on Win2k, there was multiple cygwin installations in path, the other one\n> supposedly is 1.5.5 (it's from QNX Momentics installation).\n> I had that old \"cygwin1.dll\" renamed into \"cygwin1.dll-disabled\" long\n> ago, though...\n> I can't reproduce this out of GIT context, and the error is not\n> reproducable after\n> I removed the other cygwin installation out of PATH.\n> Anyway, sorry, I should have tried this before posting.\n\nStill does not work for me. I cannot isolate the problem out of git,\nbut at the moment the only way for me to make commit_index_file to work\nis to put unlink(indexfile) before rename(cf->lockfile, indexfile).\n\nFor everyone interested, I attach cygwin's strace output here.\n"},{"id":"9706","messageId":"20051005155212.GA16391@diku.dk","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0510051556320.14244@wbgn013.biozentrum.uni-wuerzburg.de","subject":"[PATCH] Fix symbolic ref validation","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2005-10-05T15:52:12Z","receivedAt":"2005-10-05T15:52:12Z","isPatch":true,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Johannes Schindelin wrote Wed, Oct 05, 2005:\n> Hi,\n\nHello,\n\n> On Wed, 5 Oct 2005, Jonas Fonseca wrote:\n> \n> > user@machine /usr/local/dev/git/git\n> > $ git-log\n> > fatal: Not a git repository\n> > \n> > user@machine /usr/local/dev/git/git\n> > $ GIT_DIR=.git git-log | wc -l\n> > 26094\n> \n> That could have its cause in your .git/HEAD being no symlink. That happens \n> when rsync´ing the .git directory.\n\nYes, used rsync when I cloned. Seems validate_symref() was buggy. \n\n> The other errors could also stem from the fact that quite a few places \n> expect HEAD to be a symlink.\n\ngit-reset still error out ...\n\n---\n\nUse the correct buffer when validating 'ref: refs/...'\n\nSigned-off-by: Jonas Fonseca \n\n---\ndiff --git a/refs.c b/refs.c\n--- a/refs.c\n+++ b/refs.c\n@@ -46,7 +46,7 @@ int validate_symref(const char *path)\n \tlen -= 4;\n \twhile (len && isspace(*buf))\n \t\tbuf++, len--;\n-\tif (len >= 5 && !memcmp(\"refs/\", buffer, 5))\n+\tif (len >= 5 && !memcmp(\"refs/\", buf, 5))\n \t\treturn 0;\n \treturn -1;\n }\n\n-- \nJonas Fonseca\n"},{"id":"9707","messageId":"20051005155457.GA30303@trixie.casa.cgf.cx","threadId":"1969","inReplyTo":"81b0412b0510050846l2258775co117bada2d2b5a1ad@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2005-10-05T15:54:57Z","receivedAt":"2005-10-05T15:54:57Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Wed, Oct 05, 2005 at 05:46:08PM +0200, Alex Riesen wrote:\n>On 10/5/05, Alex Riesen wrote:\n>> On 10/4/05, H. Peter Anvin wrote:\n>> > > I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the\n>> > > target and returns an error (probably EPERM, but I have reasons not to trust\n>> > > strerror on that thing).\n>> > > The repository was on FAT.\n>> > > Taking \"rename(2)\" from cygwin's libiberty solved this (they unlink if link(2)\n>> > > returns EEXIST).\n>> > >\n>> > > PS: Does broken rename(2) qualify a system \"not worthy to support\"?\n>> >\n>> > I just tried this with Cygwin 1.5.18-1 and didn't have any such\n>> > problems. I tried it on NTFS, FAT and Samba, using WinXP.\n>>\n>> It's on Win2k, there was multiple cygwin installations in path, the other one\n>> supposedly is 1.5.5 (it's from QNX Momentics installation).\n>> I had that old \"cygwin1.dll\" renamed into \"cygwin1.dll-disabled\" long\n>> ago, though...\n>> I can't reproduce this out of GIT context, and the error is not\n>> reproducable after\n>> I removed the other cygwin installation out of PATH.\n>> Anyway, sorry, I should have tried this before posting.\n>\n>Still does not work for me. I cannot isolate the problem out of git,\n>but at the moment the only way for me to make commit_index_file to work\n>is to put unlink(indexfile) before rename(cf->lockfile, indexfile).\n>\n>For everyone interested, I attach cygwin's strace output here.\n\nI'm sorry that I missed this thread. I'm usually pretty alert to the word\n\"cygwin\" showing up in a subject.\n\nI'll go back and read the archives to catch up but, at the risk of\nmaking an observation that has already been made, under windows you\ncan't always rename a file that is open. Is that what's happening here?\n\n--\nChristopher Faylor\t\t\tspammer? ->\taaaspam@sourceware.org\nCygwin Co-Project Leader\t\t\t\taaaspam@duffek.com\nTimeSys, Inc.\n"},{"id":"9709","messageId":"Pine.LNX.4.63.0510050902430.28854@localhost.localdomain","threadId":"1969","inReplyTo":"20051005155457.GA30303@trixie.casa.cgf.cx","subject":"Re: First cut at git port to Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-10-05T16:09:49Z","receivedAt":"2005-10-05T16:09:49Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On 10/5/05, Alex Riesen wrote:\n\n> Still does not work for me. I cannot isolate the problem out of git,\n> but at the moment the only way for me to make commit_index_file to work\n> is to put unlink(indexfile) before rename(cf->lockfile, indexfile).\n\nI don't know how Cygwin implemented rename(), but if they used MoveFile() \nthey broke the POSIX rename() since MoveFile() fails if destination \nalready exists. They should have used MoveFileEx(MOVEFILE_REPLACE_EXISTING)\ninstead, to guarantee POSIX semantics. The symptoms you're experiencing \nmake me think this might be the case (even if it is strange, since other \nUnix software would fail the same way).\n\n\n- Davide\n"},{"id":"9710","messageId":"20051005161546.GB30303@trixie.casa.cgf.cx","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0510050902430.28854@localhost.localdomain","subject":"Re: First cut at git port to Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2005-10-05T16:15:46Z","receivedAt":"2005-10-05T16:15:46Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Wed, Oct 05, 2005 at 09:09:49AM -0700, Davide Libenzi wrote:\n>On 10/5/05, Alex Riesen wrote:\n>>Still does not work for me. I cannot isolate the problem out of git,\n>>but at the moment the only way for me to make commit_index_file to work\n>>is to put unlink(indexfile) before rename(cf->lockfile, indexfile).\n>\n>I don't know how Cygwin implemented rename(), but if they used\n>MoveFile() they broke the POSIX rename() since MoveFile() fails if\n>destination already exists. They should have used\n>MoveFileEx(MOVEFILE_REPLACE_EXISTING) instead, to guarantee POSIX\n>semantics. The symptoms you're experiencing make me think this might\n>be the case (even if it is strange, since other Unix software would\n>fail the same way).\n\nCygwin's rename is much more than just a simple wrapper around MoveFile\nor MoveFileEx. It tries hard to guarantee POSIX semantics within the\nstrictures imposed by Windows.\n--\nChristopher Faylor\t\t\tspammer? ->\taaaspam@sourceware.org\nCygwin Co-Project Leader\t\t\t\taaaspam@duffek.com\nTimeSys, Inc.\n"},{"id":"9711","messageId":"4343FE08.2080607@zytor.com","threadId":"1969","inReplyTo":"20051005161546.GB30303@trixie.casa.cgf.cx","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-05T16:23:36Z","receivedAt":"2005-10-05T16:23:36Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Christopher Faylor wrote:\n> Cygwin's rename is much more than just a simple wrapper around MoveFile\n> or MoveFileEx. It tries hard to guarantee POSIX semantics within the\n> strictures imposed by Windows.\n\nCertainly, but presumably different versions of Win32 have different \nlimitations, no?\n\n\t-hpa\n"},{"id":"9712","messageId":"20051005162801.GC30303@trixie.casa.cgf.cx","threadId":"1969","inReplyTo":"4343FE08.2080607@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2005-10-05T16:28:01Z","receivedAt":"2005-10-05T16:28:01Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Wed, Oct 05, 2005 at 09:23:36AM -0700, H. Peter Anvin wrote:\n>Christopher Faylor wrote:\n>>Cygwin's rename is much more than just a simple wrapper around MoveFile\n>>or MoveFileEx. It tries hard to guarantee POSIX semantics within the\n>>strictures imposed by Windows.\n>\n>Certainly, but presumably different versions of Win32 have different \n>limitations, no?\n\nYes, definitely. That's why the Cygwin rename code (and unlink code for\nthat matter) is so headache-inducing.\n\nFWIW, I just looked at the source and, AFAICT, if rename() is setting\nEPERM on Windows NT/2000/XP, it should be the result of a failing\nMoveFileEx (old, new, MOVEFILE_REPLACE_EXISTING).\n--\nChristopher Faylor\t\t\tspammer? ->\taaaspam@sourceware.org\nCygwin Co-Project Leader\t\t\t\taaaspam@duffek.com\nTimeSys, Inc.\n"},{"id":"9714","messageId":"7vk6grykdo.fsf@assigned-by-dhcp.cox.net","threadId":"1969","inReplyTo":"20051005155212.GA16391@diku.dk","subject":"Re: [PATCH] Fix symbolic ref validation","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-05T16:54:43Z","receivedAt":"2005-10-05T16:54:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonas Fonseca writes:\n\n> Yes, used rsync when I cloned. Seems validate_symref() was buggy. \n>\n>> The other errors could also stem from the fact that quite a few places \n>> expect HEAD to be a symlink.\n>\n> git-reset still error out ...\n>\n> ---\n>\n> Use the correct buffer when validating 'ref: refs/...'\n>\n> Signed-off-by: Jonas Fonseca \n>\n> ---\n> diff --git a/refs.c b/refs.c\n\nThanks.\n\nOne request, not just to Jonas. Please do not use '^---$' to\nseparate the introductory discussion and the real commit log\nmessage.\n\nLinus style (recently the kernel list had a thread on this as\nwell) is to have the commit log upfront with signoff, three-dash\nline, optional discussion and diffstat, and then diff.\n\nI do not mind seeing discussion upfront personally [*1*], but\nthe thing is the tool treats everything after the first '^---$' \nsomething to be fed to patch, and does not treat it as the\ncommit log message.\n\n\n[Footnote]\n\n*1* ...but remember, Linus does.\n"},{"id":"9717","messageId":"Pine.LNX.4.63.0510051028570.29565@localhost.localdomain","threadId":"1969","inReplyTo":"20051005161546.GB30303@trixie.casa.cgf.cx","subject":"Re: First cut at git port to Cygwin","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-10-05T17:29:31Z","receivedAt":"2005-10-05T17:29:31Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Wed, 5 Oct 2005, Christopher Faylor wrote:\n\n> On Wed, Oct 05, 2005 at 09:09:49AM -0700, Davide Libenzi wrote:\n>> On 10/5/05, Alex Riesen wrote:\n>>> Still does not work for me. I cannot isolate the problem out of git,\n>>> but at the moment the only way for me to make commit_index_file to work\n>>> is to put unlink(indexfile) before rename(cf->lockfile, indexfile).\n>>\n>> I don't know how Cygwin implemented rename(), but if they used\n>> MoveFile() they broke the POSIX rename() since MoveFile() fails if\n>> destination already exists. They should have used\n>> MoveFileEx(MOVEFILE_REPLACE_EXISTING) instead, to guarantee POSIX\n>> semantics. The symptoms you're experiencing make me think this might\n>> be the case (even if it is strange, since other Unix software would\n>> fail the same way).\n>\n> Cygwin's rename is much more than just a simple wrapper around MoveFile\n> or MoveFileEx. It tries hard to guarantee POSIX semantics within the\n> strictures imposed by Windows.\n\nOuch, IC:\n\nhttp://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/syscalls.cc?rev=1.390&content-type=text/plain&cvsroot=src\n\nThat's quite some code.\n\n\n\n- Davide\n"},{"id":"9720","messageId":"20051005191741.GA25493@steel.home","threadId":"1969","inReplyTo":"20051005155457.GA30303@trixie.casa.cgf.cx","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-05T19:17:41Z","receivedAt":"2005-10-05T19:17:41Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Christopher Faylor, Wed, Oct 05, 2005 17:54:57 +0200:\n> >Still does not work for me. I cannot isolate the problem out of git,\n> >but at the moment the only way for me to make commit_index_file to work\n> >is to put unlink(indexfile) before rename(cf->lockfile, indexfile).\n> >\n> >For everyone interested, I attach cygwin's strace output here.\n> \n> I'm sorry that I missed this thread. I'm usually pretty alert to the word\n> \"cygwin\" showing up in a subject.\n> \n> I'll go back and read the archives to catch up but, at the risk of\n> making an observation that has already been made, under windows you\n> can't always rename a file that is open. Is that what's happening here?\n> \n\nDon't think so, but will check in about 10 hrs. The code in question\nis in index.c, commit_index_file.\n"},{"id":"9722","messageId":"20051005202947.GA6184@trixie.casa.cgf.cx","threadId":"1969","inReplyTo":"20051005191741.GA25493@steel.home","subject":"Re: First cut at git port to Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2005-10-05T20:29:47Z","receivedAt":"2005-10-05T20:29:47Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Wed, Oct 05, 2005 at 09:17:41PM +0200, Alex Riesen wrote:\n>Christopher Faylor, Wed, Oct 05, 2005 17:54:57 +0200:\n>> >Still does not work for me. I cannot isolate the problem out of git,\n>> >but at the moment the only way for me to make commit_index_file to work\n>> >is to put unlink(indexfile) before rename(cf->lockfile, indexfile).\n>> >\n>> >For everyone interested, I attach cygwin's strace output here.\n>> \n>> I'm sorry that I missed this thread. I'm usually pretty alert to the word\n>> \"cygwin\" showing up in a subject.\n>> \n>> I'll go back and read the archives to catch up but, at the risk of\n>> making an observation that has already been made, under windows you\n>> can't always rename a file that is open. Is that what's happening here?\n>> \n>\n>Don't think so, but will check in about 10 hrs. The code in question\n>is in index.c, commit_index_file.\n\nOk. Looks pretty simple. FWIW, I've just built git on windows and I\ndon't see this behavior. For the most part, it \"just works\".\n\nI do see the gitk behavior but I'm tk illiterate too, unfortunately, so\nI can't help there.\n\nCygwin's tcl/tk is a funny beast. It is primarily included (by me) to\nallow for the operation of the insight debugger and is more windows than\nPOSIX. As was noted, it doesn't interact with Cygwin/X but just draws\nwindows using the Windows API.\n\nSo, tcl/tk are just barely supported in Cygwin currently. I'm actually\na little surprised that it works as well as it does with gitk.\n--\nChristopher Faylor\t\t\tspammer? ->\taaaspam@sourceware.org\nCygwin Co-Project Leader\t\t\t\taaaspam@duffek.com\nTimeSys, Inc.\n"},{"id":"9758","messageId":"81b0412b0510060205v4cd510c9wb4b06a3ed9242c8@mail.gmail.com","threadId":"1969","inReplyTo":"20051005202947.GA6184@trixie.casa.cgf.cx","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-06T09:05:57Z","receivedAt":"2005-10-06T09:05:57Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 10/5/05, Christopher Faylor wrote:\n> >Don't think so, but will check in about 10 hrs. The code in question\n> >is in index.c, commit_index_file.\n>\n> Ok. Looks pretty simple. FWIW, I've just built git on windows and I\n> don't see this behavior. For the most part, it \"just works\".\n\nThanks for the hint. There are open files involved (both index.lock and index).\nI attach the patch which closes index.lock (this is not really needed, btw:\nrename works even without closing index.lock) and unmaps the index\n(a bit too intrusive). The patch fixes only update-index.c (the one I had\nproblems with), there probably are other places were the situation is alike.\n\nI don't like the patch (and win32 at all; hence the offending comment),\nso use it only unless there is no other possibility to workaround.\nI specifically do not request its inclusion into official branch\n(even though Junio is cc'ed).\n"},{"id":"9759","messageId":"81b0412b0510060307q431b64edt4196553bce28346c@mail.gmail.com","threadId":"1969","inReplyTo":"81b0412b0510060205v4cd510c9wb4b06a3ed9242c8@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-06T10:07:53Z","receivedAt":"2005-10-06T10:07:53Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 10/6/05, Alex Riesen wrote:\n> (a bit too intrusive). The patch fixes only update-index.c (the one I had\n> problems with), there probably are other places were the situation is alike.\n\nof course there are \"other places\". Please, try the attached patch instead.\n\nFor the record: the patch is supposed to help people with\n\"Unable to write new cachefile\" kind of errors.\n"},{"id":"9793","messageId":"81b0412b0510070544v3e7cf0b4n521db8ff7e4e335a@mail.gmail.com","threadId":"1969","inReplyTo":"81b0412b0510060307q431b64edt4196553bce28346c@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-07T12:44:07Z","receivedAt":"2005-10-07T12:44:07Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 10/6/05, Alex Riesen wrote:\n> > (a bit too intrusive). The patch fixes only update-index.c (the one I had\n> > problems with), there probably are other places were the situation is alike.\n>\n> of course there are \"other places\". Please, try the attached patch instead.\n>\n> For the record: the patch is supposed to help people with\n> \"Unable to write new cachefile\" kind of errors.\n\nJust as I thought the situation improved (by closing index.lock and\nunmapping index),\nit suddenly get worse: now I'm stuck on git-pull.\n\ngit-merge-index (called at some point by git-pull) maps the index in, and starts\ngit-merge-one-file for each (or the given) entry in the index.\ngit-merge-one-file\ncalls git-update-index, which wants to update the index. Which doesn't work,\nbecause it's locked by that piece of s$%^.\n\nThe only working walkaround for me atm is unlinking indexfile before rename in\ncommit_index_file :(\n"},{"id":"9796","messageId":"Pine.LNX.4.64.0510070828270.31407@g5.osdl.org","threadId":"1969","inReplyTo":"81b0412b0510070544v3e7cf0b4n521db8ff7e4e335a@mail.gmail.com","subject":"Re: First cut at git port to Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-07T15:34:19Z","receivedAt":"2005-10-07T15:34:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 Oct 2005, Alex Riesen wrote:\n>\n> it suddenly get worse: now I'm stuck on git-pull.\n> \n> git-merge-index (called at some point by git-pull) maps the index in, and starts\n> git-merge-one-file for each (or the given) entry in the index.\n> git-merge-one-file\n> calls git-update-index, which wants to update the index. Which doesn't work,\n> because it's locked by that piece of s$%^.\n\nNOTE! git doesn't use mmap() because it _needs_ to use mmap(), but because \nit was simple to do that way, and it's a total idiosyncracy of mine that I \noften try to mmap the data. I often also tend to do my own allocators \ninstead of using malloc() (see my \"sparse\" project in case you're \ninterested in other idiosyncracies of mine - macros to do list traversal \netc).\n\nThe fact is, \"mmap()\" isn't really any better than \"read()\": it has some \nadvantages wrt memory management for the kernel, which is probably one big \nreason why I do it, but quite frankly, if you were to change every single \nmmap() to be a \"map_file()\" instead, and made it optional whether it used \nmmap() or \"malloc + read()\", I personally don't think it would be \nhorrible.\n\nAnd it might make things much simpler for portability. The \"use mmap\" \napproach is very much a unixism, particularly the way unix people do it \n(mmap followed by close, making the file descriptor \"go away\"). Sure, \nother OS's have mmap too, but I think on them it tends to be less commonly \nused.\n\n\t\t\tLinus\n"},{"id":"9808","messageId":"20051007205450.GA14827@steel.home","threadId":"1969","inReplyTo":"Pine.LNX.4.64.0510070828270.31407@g5.osdl.org","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-07T20:54:50Z","receivedAt":"2005-10-07T20:54:50Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Fri, Oct 07, 2005 17:34:19 +0200:\n> > it suddenly get worse: now I'm stuck on git-pull.\n> > \n> > git-merge-index (called at some point by git-pull) maps the index\n> > in, and starts git-merge-one-file for each (or the given) entry in\n> > the index. git-merge-one-file calls git-update-index, which wants\n> > to update the index. Which doesn't work, because it's locked by\n> > that piece of s$%^.\n> \n> NOTE! git doesn't use mmap() because it _needs_ to use mmap(), but because \n> it was simple to do that way, and it's a total idiosyncracy of mine that I \n> often try to mmap the data. I often also tend to do my own allocators \n> instead of using malloc() (see my \"sparse\" project in case you're \n> interested in other idiosyncracies of mine - macros to do list traversal \n> etc).\n> \n> The fact is, \"mmap()\" isn't really any better than \"read()\": it has some \n> advantages wrt memory management for the kernel, which is probably one big \n> reason why I do it, but quite frankly, if you were to change every single \n> mmap() to be a \"map_file()\" instead, and made it optional whether it used \n> mmap() or \"malloc + read()\", I personally don't think it would be \n> horrible.\n> \n> And it might make things much simpler for portability. The \"use mmap\" \n> approach is very much a unixism, particularly the way unix people do it \n> (mmap followed by close, making the file descriptor \"go away\"). Sure, \n> other OS's have mmap too, but I think on them it tends to be less commonly \n> used.\n\n\"Sounds like a thinly veiled threat or a very effective prodding\" 8)\n\n---\n\nMake read_cache copy the index into memory, to improve portability on\nother OS's which have mmap too, tend to use it less commonly.\n\nSigned-off-by: Alex Riesen \n\ndiff --git a/read-cache.c b/read-cache.c\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -497,9 +497,11 @@ int read_cache(void)\n \toffset = sizeof(*hdr);\n \tfor (i = 0; i < active_nr; i++) {\n \t\tstruct cache_entry *ce = map + offset;\n-\t\toffset = offset + ce_size(ce);\n-\t\tactive_cache[i] = ce;\n+\t\tsize_t size = ce_size(ce);\n+\t\toffset = offset + size;\n+\t\tactive_cache[i] = malloc(ce, size);\n \t}\n+\tmunmap(map, size);\n \treturn active_nr;\n \n unmap:\n"},{"id":"9809","messageId":"20051007212250.GA1423@steel.home","threadId":"1969","inReplyTo":"20051007205450.GA14827@steel.home","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"fork0@users.sourceforge.net","sentAt":"2005-10-07T21:22:50Z","receivedAt":"2005-10-07T21:22:50Z","isPatch":false,"sender":{"key":"fork0@users.sourceforge.net","avatar":null},"body":"Alex Riesen, Fri, Oct 07, 2005 22:54:50 +0200:\n> Linus Torvalds, Fri, Oct 07, 2005 17:34:19 +0200:\n> > > it suddenly get worse: now I'm stuck on git-pull.\n> > > \n> > > git-merge-index (called at some point by git-pull) maps the index\n> > > in, and starts git-merge-one-file for each (or the given) entry in\n> > > the index. git-merge-one-file calls git-update-index, which wants\n> > > to update the index. Which doesn't work, because it's locked by\n> > > that piece of s$%^.\n> > \n> > NOTE! git doesn't use mmap() because it _needs_ to use mmap(), but because \n> > it was simple to do that way, and it's a total idiosyncracy of mine that I \n> > often try to mmap the data. I often also tend to do my own allocators \n> > instead of using malloc() (see my \"sparse\" project in case you're \n> > interested in other idiosyncracies of mine - macros to do list traversal \n> > etc).\n> > \n> > The fact is, \"mmap()\" isn't really any better than \"read()\": it has some \n> > advantages wrt memory management for the kernel, which is probably one big \n> > reason why I do it, but quite frankly, if you were to change every single \n> > mmap() to be a \"map_file()\" instead, and made it optional whether it used \n> > mmap() or \"malloc + read()\", I personally don't think it would be \n> > horrible.\n> > \n> > And it might make things much simpler for portability. The \"use mmap\" \n> > approach is very much a unixism, particularly the way unix people do it \n> > (mmap followed by close, making the file descriptor \"go away\"). Sure, \n> > other OS's have mmap too, but I think on them it tends to be less commonly \n> > used.\n> \n> \"Sounds like a thinly veiled threat or a very effective prodding\" 8)\n> \n\nJunio C Hamano, Fri, Oct 07, 2005 23:00:02 +0200:\n> Huh? where is your memcpy?\n\nUnbelievable... I actually tested the change! But not _the_ patch.\nThanks. Next time, hit me :)\n\n---\n\nMake read_cache copy the index into memory, to improve portability on\nother OS's which have mmap too, tend to use it less commonly.\n\nSigned-off-by: Alex Riesen \n\ndiff --git a/read-cache.c b/read-cache.c\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -497,9 +497,12 @@ int read_cache(void)\n \toffset = sizeof(*hdr);\n \tfor (i = 0; i < active_nr; i++) {\n \t\tstruct cache_entry *ce = map + offset;\n-\t\toffset = offset + ce_size(ce);\n-\t\tactive_cache[i] = ce;\n+\t\tsize_t size = ce_size(ce);\n+\t\tstruct cache_entry *newce = malloc(size);\n+\t\toffset = offset + size;\n+\t\tactive_cache[i] = memcpy(newce, ce, size);\n \t}\n+\tmunmap(map, size);\n \treturn active_nr;\n \n unmap:\n"},{"id":"9810","messageId":"4346E8AC.5030503@citi.umich.edu","threadId":"1969","inReplyTo":"20051007212250.GA1423@steel.home","subject":"Re: First cut at git port to Cygwin","fromName":"Chuck Lever","fromEmail":"cel@citi.umich.edu","sentAt":"2005-10-07T21:29:16Z","receivedAt":"2005-10-07T21:29:16Z","isPatch":false,"sender":{"key":"cel@citi.umich.edu","avatar":null},"body":"Alex Riesen wrote:\n> Make read_cache copy the index into memory, to improve portability on\n> other OS's which have mmap too, tend to use it less commonly.\n> \n> Signed-off-by: Alex Riesen \n> \n> diff --git a/read-cache.c b/read-cache.c\n> --- a/read-cache.c\n> +++ b/read-cache.c\n> @@ -497,9 +497,12 @@ int read_cache(void)\n> \toffset = sizeof(*hdr);\n> \tfor (i = 0; i < active_nr; i++) {\n> \t\tstruct cache_entry *ce = map + offset;\n> -\t\toffset = offset + ce_size(ce);\n> -\t\tactive_cache[i] = ce;\n> +\t\tsize_t size = ce_size(ce);\n> +\t\tstruct cache_entry *newce = malloc(size);\n> +\t\toffset = offset + size;\n> +\t\tactive_cache[i] = memcpy(newce, ce, size);\n> \t}\n> +\tmunmap(map, size);\n> \treturn active_nr;\n> \n> unmap:\n\ns/malloc/xmalloc/\n\n\nbegin:vcard\nfn:Chuck Lever\nn:Lever;Charles\norg:Network Appliance, Incorporated;Linux NFS Client Development\nadr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA\nemail;internet:cel@citi.umich.edu\ntitle:Member of Technical Staff\ntel;work:+1 734 763 4415\ntel;fax:+1 734 763 4434\ntel;home:+1 734 668 1089\nx-mozilla-html:FALSE\nurl:http://www.monkey.org/~cel/\nversion:2.1\nend:vcard\n\n"},{"id":"9811","messageId":"20051007213952.GA8821@steel.home","threadId":"1969","inReplyTo":"4346E8AC.5030503@citi.umich.edu","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"fork0@users.sourceforge.net","sentAt":"2005-10-07T21:39:52Z","receivedAt":"2005-10-07T21:39:52Z","isPatch":false,"sender":{"key":"fork0@users.sourceforge.net","avatar":null},"body":"Chuck Lever, Fri, Oct 07, 2005 23:29:16 +0200:\n> s/malloc/xmalloc/\n\nIt's not that funny after second repost...\n\n---\n\nMake read_cache copy the index into memory, to improve portability on\nother OS's which have mmap too, tend to use it less commonly.\n\nSigned-off-by: Alex Riesen \n\ndiff --git a/read-cache.c b/read-cache.c\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -497,9 +497,12 @@ int read_cache(void)\n \toffset = sizeof(*hdr);\n \tfor (i = 0; i < active_nr; i++) {\n \t\tstruct cache_entry *ce = map + offset;\n-\t\toffset = offset + ce_size(ce);\n-\t\tactive_cache[i] = ce;\n+\t\tsize_t size = ce_size(ce);\n+\t\tstruct cache_entry *newce = xmalloc(size);\n+\t\toffset = offset + size;\n+\t\tactive_cache[i] = memcpy(newce, ce, size);\n \t}\n+\tmunmap(map, size);\n \treturn active_nr;\n \n unmap:\n"},{"id":"9823","messageId":"20051007234547.GC8893@steel.home","threadId":"1969","inReplyTo":"7vfyrdyre5.fsf@assigned-by-dhcp.cox.net","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-07T23:45:47Z","receivedAt":"2005-10-07T23:45:47Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Fri, Oct 07, 2005 23:00:02 +0200:\n> > \"Sounds like a thinly veiled threat or a very effective prodding\" 8)\n> > ---\n> >\n> > Make read_cache copy the index into memory, to improve portability on\n> > other OS's which have mmap too, tend to use it less commonly.\n> >\n> \n> Huh? where is your memcpy?\n> \n\nJunio, unless there already are pressing reasons to put the patch in\nGIT, could you postpone its inclusion (if you ever considered)? Or at\nleast put \"#ifdef __cygwin\" (I hope this is the define) around it?\n\nIt just so ugly... And besides, GIT reportedly works without problems\nfor many people even without it.\n\nAnyway, the patch is out, so anyone with the problems can just patch\ntheir copy to workaround this specific win2k problem.\n\nThanks,\nAlex\n"},{"id":"9826","messageId":"20051008010021.GA29261@gentoo.org","threadId":"1969","inReplyTo":"20051007234547.GC8893@steel.home","subject":"Re: First cut at git port to Cygwin","fromName":"Elfyn McBratney","fromEmail":"beu@gentoo.org","sentAt":"2005-10-08T01:00:21Z","receivedAt":"2005-10-08T01:00:21Z","isPatch":false,"sender":{"key":"beu@gentoo.org","avatar":null},"body":"On Sat, Oct 08, 2005 at 01:45:47AM +0200, Alex Riesen wrote:\n > Junio C Hamano, Fri, Oct 07, 2005 23:00:02 +0200:\n > > > \"Sounds like a thinly veiled threat or a very effective prodding\" 8)\n > > > ---\n > > >\n > > > Make read_cache copy the index into memory, to improve portability on\n > > > other OS's which have mmap too, tend to use it less commonly.\n > > >\n > > \n > > Huh? where is your memcpy?\n > > \n > \n > Junio, unless there already are pressing reasons to put the patch in\n > GIT, could you postpone its inclusion (if you ever considered)? Or at\n > least put \"#ifdef __cygwin\" (I hope this is the define) around it?\n\nClose ;) - the define is \"__CYGWIN__\".\n\nBest,\nElfyn\n\n-- \nElfyn McBratney\nGentoo Developer/Perl Team Lead\nbeu/irc.freenode.net http://dev.gentoo.org/~beu/\n+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc\n\nPGP Key ID: 0x69DF17AD\nPGP Key Fingerprint:\n DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD\n"},{"id":"9831","messageId":"Pine.LNX.4.64.0510080900510.31407@g5.osdl.org","threadId":"1969","inReplyTo":"20051007213952.GA8821@steel.home","subject":"Re: First cut at git port to Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-08T16:11:03Z","receivedAt":"2005-10-08T16:11:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 Oct 2005, Alex Riesen wrote:\n> \n> Make read_cache copy the index into memory, to improve portability on\n> other OS's which have mmap too, tend to use it less commonly.\n\nI really think that you should just get rid of the mmap.\n\nAs it is, you're just slowing the code down on sane architectures. That's \nnot good.\n\nSo I'd suggest something like this instead.\n\nTotally untested, of course.\n\n\t\tLinus\n\n----\ndiff --git a/read-cache.c b/read-cache.c\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -454,13 +454,39 @@ static int verify_hdr(struct cache_heade\n \treturn 0;\n }\n \n+static void *map_index_file(int fd, size_t size)\n+{\n+\tvoid *map;\n+#ifdef NO_MMAP\n+\tmap = malloc(size);\n+\tif (!map)\n+\t\tdie(\"Unable to allocate index file mapping\");\n+\tif (read(fd, map, size) != size)\n+\t\tdie(\"Unable to read %z bytes from inde\n+#else\n+\tmap = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);\n+\tif (map == MAP_FAILED)\n+\t\tdie(\"index file mmap failed (%s)\", strerror(errno));\n+#endif\n+\treturn map;\n+}\n+\n+static void unmap_index_file(void *map, size_t size)\n+{\n+#ifdef NO_MMAP\n+\tfree(map);\n+#else\n+\tmunmap(map, size);\n+#endif\n+}\n+\n int read_cache(void)\n {\n \tint fd, i;\n \tstruct stat st;\n \tunsigned long size, offset;\n-\tvoid *map;\n \tstruct cache_header *hdr;\n+\tvoid *map;\n \n \terrno = EBUSY;\n \tif (active_cache)\n@@ -475,16 +501,15 @@ int read_cache(void)\n \t}\n \n \tsize = 0; // avoid gcc warning\n-\tmap = MAP_FAILED;\n-\tif (!fstat(fd, &st)) {\n-\t\tsize = st.st_size;\n-\t\terrno = EINVAL;\n-\t\tif (size >= sizeof(struct cache_header) + 20)\n-\t\t\tmap = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);\n-\t}\n+\tif (fstat(fd, &st))\n+\t\tdie(\"unable to fstat index file\");\n+\n+\tsize = st.st_size;\n+\terrno = EINVAL;\n+\tif (size < sizeof(struct cache_header) + 20)\n+\t\tgoto corrupt;\n+\tmap = map_index_file(fd, size);\n \tclose(fd);\n-\tif (map == MAP_FAILED)\n-\t\tdie(\"index file mmap failed (%s)\", strerror(errno));\n \n \thdr = map;\n \tif (verify_hdr(hdr, size) < 0)\n@@ -503,8 +528,9 @@ int read_cache(void)\n \treturn active_nr;\n \n unmap:\n-\tmunmap(map, size);\n+\tunmap_index_file(map, size);\n \terrno = EINVAL;\n+corrupt:\n \tdie(\"index file corrupt\");\n }\n \n"},{"id":"9834","messageId":"20051008173812.GA20870@gentoo.org","threadId":"1969","inReplyTo":"Pine.LNX.4.64.0510080900510.31407@g5.osdl.org","subject":"Re: First cut at git port to Cygwin","fromName":"Elfyn McBratney","fromEmail":"beu@gentoo.org","sentAt":"2005-10-08T17:38:13Z","receivedAt":"2005-10-08T17:38:13Z","isPatch":false,"sender":{"key":"beu@gentoo.org","avatar":null},"body":"On Sat, Oct 08, 2005 at 09:11:03AM -0700, Linus Torvalds wrote:\n > \n > On Fri, 7 Oct 2005, Alex Riesen wrote:\n > > \n > > Make read_cache copy the index into memory, to improve portability on\n > > other OS's which have mmap too, tend to use it less commonly.\n > \n > I really think that you should just get rid of the mmap.\n > \n > As it is, you're just slowing the code down on sane architectures. That's \n > not good.\n > \n > So I'd suggest something like this instead.\n > \n > Totally untested, of course.\n > \n > \t\tLinus\n\nSlightly adjusted diff below so it compiles ;) (Note: only the second\ndie() un hunk #1 was changed.)\n\nBest,\nElfyn\n\n----\ndiff --git a/read-cache.c b/read-cache.c\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -454,13 +454,39 @@ static int verify_hdr(struct cache_heade\n \treturn 0;\n }\n \n+static void *map_index_file(int fd, size_t size)\n+{\n+\tvoid *map;\n+#ifdef NO_MMAP\n+\tmap = malloc(size);\n+\tif (!map)\n+\t\tdie(\"Unable to allocate index file mapping\");\n+\tif (read(fd, map, size) != size)\n+\t\tdie(\"Unable to read %z bytes from index\", size);\n+#else\n+\tmap = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);\n+\tif (map == MAP_FAILED)\n+\t\tdie(\"index file mmap failed (%s)\", strerror(errno));\n+#endif\n+\treturn map;\n+}\n+\n+static void unmap_index_file(void *map, size_t size)\n+{\n+#ifdef NO_MMAP\n+\tfree(map);\n+#else\n+\tmunmap(map, size);\n+#endif\n+}\n+\n int read_cache(void)\n {\n \tint fd, i;\n \tstruct stat st;\n \tunsigned long size, offset;\n-\tvoid *map;\n \tstruct cache_header *hdr;\n+\tvoid *map;\n \n \terrno = EBUSY;\n \tif (active_cache)\n@@ -475,16 +501,15 @@ int read_cache(void)\n \t}\n \n \tsize = 0; // avoid gcc warning\n-\tmap = MAP_FAILED;\n-\tif (!fstat(fd, &st)) {\n-\t\tsize = st.st_size;\n-\t\terrno = EINVAL;\n-\t\tif (size >= sizeof(struct cache_header) + 20)\n-\t\t\tmap = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);\n-\t}\n+\tif (fstat(fd, &st))\n+\t\tdie(\"unable to fstat index file\");\n+\n+\tsize = st.st_size;\n+\terrno = EINVAL;\n+\tif (size < sizeof(struct cache_header) + 20)\n+\t\tgoto corrupt;\n+\tmap = map_index_file(fd, size);\n \tclose(fd);\n-\tif (map == MAP_FAILED)\n-\t\tdie(\"index file mmap failed (%s)\", strerror(errno));\n \n \thdr = map;\n \tif (verify_hdr(hdr, size) < 0)\n@@ -503,8 +528,9 @@ int read_cache(void)\n \treturn active_nr;\n \n unmap:\n-\tmunmap(map, size);\n+\tunmap_index_file(map, size);\n \terrno = EINVAL;\n+corrupt:\n \tdie(\"index file corrupt\");\n }\n\n\n-- \nElfyn McBratney\nGentoo Developer/Perl Team Lead\nbeu/irc.freenode.net http://dev.gentoo.org/~beu/\n+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc\n\nPGP Key ID: 0x69DF17AD\nPGP Key Fingerprint:\n DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD\n"},{"id":"9836","messageId":"20051008174306.GB20870@gentoo.org","threadId":"1969","inReplyTo":"Pine.LNX.4.64.0510080900510.31407@g5.osdl.org","subject":"Re: First cut at git port to Cygwin","fromName":"Elfyn McBratney","fromEmail":"beu@gentoo.org","sentAt":"2005-10-08T17:43:06Z","receivedAt":"2005-10-08T17:43:06Z","isPatch":false,"sender":{"key":"beu@gentoo.org","avatar":null},"body":"Er, apologies for the dups - postfix crapped itself :/\n\n*goes and stands in the corner donning the 'D' hat*\n\n-- \nElfyn McBratney\nGentoo Developer/Perl Team Lead\nbeu/irc.freenode.net http://dev.gentoo.org/~beu/\n+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc\n\nPGP Key ID: 0x69DF17AD\nPGP Key Fingerprint:\n DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD\n"},{"id":"9839","messageId":"Pine.LNX.4.63.0510082023130.25971@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"1969","inReplyTo":"Pine.LNX.4.64.0510080900510.31407@g5.osdl.org","subject":"Re: First cut at git port to Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-08T18:27:06Z","receivedAt":"2005-10-08T18:27:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 8 Oct 2005, Linus Torvalds wrote:\n\n> I really think that you should just get rid of the mmap.\n> \n> As it is, you're just slowing the code down on sane architectures. That's \n> not good.\n> \n> So I'd suggest something like this instead.\n> \n> Totally untested, of course.\n\nAm I missing something? I don't see where the changes are written back to \nthe fd. After all, mmap() is called with PROT_WRITE...\n\n*shameless plug* Of course, this problem does not come up with my NO_MMAP \npatch.\n\nCiao,\nDscho\n"},{"id":"9841","messageId":"7vr7avrgr2.fsf@assigned-by-dhcp.cox.net","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0510082023130.25971@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: First cut at git port to Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-08T18:44:01Z","receivedAt":"2005-10-08T18:44:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Am I missing something? I don't see where the changes are written back to \n> the fd. After all, mmap() is called with PROT_WRITE...\n\nPROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\ncorrectly we do not write file via mmap -- at least we do not\nintend to.\n\n - index file is mapped for reading, long ago it was mapped\n read-only but these days we do PROT_WRITE, but updates are\n done via opening a new file and writing afresh.\n\n - objects are mapped for reading, but, never updated once\n created. Creation side is regular open - write - close.\n\n - diff reads original by mapping, but obviously has no business\n writing.\n\n - local-fetch reads original by mapping for copying.\n\n> *shameless plug* Of course, this problem does not come up with\n> my NO_MMAP patch.\n\nYes. It might have been overkill that you supported writing\nchanges back, though.\n. \n"},{"id":"9843","messageId":"20051008184925.GA6347@steel.home","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0510082023130.25971@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: First cut at git port to Cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-10-08T18:49:25Z","receivedAt":"2005-10-08T18:49:25Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Sat, Oct 08, 2005 20:27:06 +0200:\n> > I really think that you should just get rid of the mmap.\n> > \n> > As it is, you're just slowing the code down on sane architectures. That's \n> > not good.\n> > \n> > So I'd suggest something like this instead.\n> > \n> > Totally untested, of course.\n> \n> Am I missing something? I don't see where the changes are written back to \n> the fd. After all, mmap() is called with PROT_WRITE...\n\nIt's just becase the file is open for reading only.\nAlso, it is not an mmap/unmap implementation. Just reading cache in.\n"},{"id":"9845","messageId":"Pine.LNX.4.63.0510082100020.26626@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"1969","inReplyTo":"7vr7avrgr2.fsf@assigned-by-dhcp.cox.net","subject":"Re: First cut at git port to Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-08T19:04:44Z","receivedAt":"2005-10-08T19:04:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 8 Oct 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Am I missing something? I don't see where the changes are written back to \n> > the fd. After all, mmap() is called with PROT_WRITE...\n> \n> PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n> correctly we do not write file via mmap -- at least we do not\n> intend to.\n\nAhh! Reading the man page helps!\n\n> Yes. It might have been overkill that you supported writing\n> changes back, though.\n\nSure. Something like this?\n\ndiff --git a/compat/mmap.c b/compat/mmap.c\nindex fca6321..fda39fc 100644\n--- a/compat/mmap.c\n+++ b/compat/mmap.c\n@@ -49,7 +49,7 @@ void *gitfakemmap(void *start, size_t le\n \t\tn += count;\n \t}\n \n-\tif(prot & PROT_WRITE) {\n+\tif((prot & PROT_WRITE) && !(flags & MAP_PRIVATE)) {\n \t\tfakemmapwritable *next = xmalloc(sizeof(fakemmapwritable));\n \t\tnext->start = start;\n \t\tnext->length = length;\n"},{"id":"9847","messageId":"7vk6gnpvf9.fsf@assigned-by-dhcp.cox.net","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0510082100020.26626@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: First cut at git port to Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-08T21:10:02Z","receivedAt":"2005-10-08T21:10:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n>> correctly we do not write file via mmap -- at least we do not\n>> intend to.\n>\n> Ahh! Reading the man page helps!\n>\n>> Yes. It might have been overkill that you supported writing\n>> changes back, though.\n>\n> Sure. Something like this?\n\nNot, really. What I meant was to rip out the writing out\naltogether, and perhaps making sure that the caller never calls\nus without MAP_PRIVATE.\n"},{"id":"9849","messageId":"Pine.LNX.4.63.0510090004370.30110@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"1969","inReplyTo":"7vk6gnpvf9.fsf@assigned-by-dhcp.cox.net","subject":"Re: First cut at git port to Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-08T22:06:00Z","receivedAt":"2005-10-08T22:06:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 8 Oct 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Sure. Something like this?\n> \n> Not, really. What I meant was to rip out the writing out\n> altogether, and perhaps making sure that the caller never calls\n> us without MAP_PRIVATE.\n\nHow about this, then?\n\n[PATCH] If NO_MMAP is defined, fake mmap() and munmap()\n\nSince some platforms do not support mmap() at all, and others do only just so,\nthis patch introduces the option to fake mmap() and munmap() by malloc()ing the\nregion explicitely.\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n Makefile | 6 ++++++\n cache.h | 16 ++++++++++++++++\n compat/mmap.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++\n mailsplit.c | 1 -\n 4 files changed, 73 insertions(+), 1 deletions(-)\n create mode 100644 compat/mmap.c\n\napplies-to: 274542bcbc891cca353c2728ac4075df3d1d2c0d\ned334e3e2276fe9d41ed78917544ef6a3fa87eb7\ndiff --git a/Makefile b/Makefile\nindex 1bdf4de..7ca77cf 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -27,6 +27,8 @@\n # Define NEEDS_SOCKET if linking with libc is not enough (SunOS,\n # Patrick Mauritz).\n #\n+# Define NO_MMAP if you want to avoid mmap.\n+#\n # Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.\n #\n # Define NO_IPV6 if you lack IPv6 support and getaddrinfo().\n@@ -258,6 +260,10 @@ ifdef NO_STRCASESTR\n \tDEFINES += -Dstrcasestr=gitstrcasestr\n \tLIB_OBJS += compat/strcasestr.o\n endif\n+ifdef NO_MMAP\n+\tDEFINES += -Dmmap=gitfakemmap -Dmunmap=gitfakemunmap -DNO_MMAP\n+\tLIB_OBJS += compat/mmap.o\n+endif\n ifdef NO_IPV6\n \tDEFINES += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in\n endif\ndiff --git a/cache.h b/cache.h\nindex 514adb8..5987d4c 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -11,7 +11,9 @@\n #include \n #include \n #include \n+#ifndef NO_MMAP\n #include \n+#endif\n #include \n #include \n #include \n@@ -356,4 +358,18 @@ extern void packed_object_info_detail(st\n /* Dumb servers support */\n extern int update_server_info(int);\n \n+#ifdef NO_MMAP\n+\n+#ifndef PROT_READ\n+#define PROT_READ 1\n+#define PROT_WRITE 2\n+#define MAP_PRIVATE 1\n+#define MAP_FAILED ((void*)-1)\n+#endif\n+\n+extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);\n+extern int gitfakemunmap(void *start, size_t length);\n+\n+#endif\n+\n #endif /* CACHE_H */\ndiff --git a/compat/mmap.c b/compat/mmap.c\nnew file mode 100644\nindex 0000000..3f035a0\n--- /dev/null\n+++ b/compat/mmap.c\n@@ -0,0 +1,51 @@\n+#include \n+#include \n+#include \n+#include \n+#include \"../cache.h\"\n+\n+void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)\n+{\n+\tint n = 0;\n+\n+\tif(start != NULL || !(flags & MAP_PRIVATE))\n+\t\tdie(\"Invalid usage of gitfakemmap.\");\n+\n+\tif(lseek(fd, offset, SEEK_SET)<0) {\n+\t\terrno = EINVAL;\n+\t\treturn MAP_FAILED;\n+\t}\n+\n+\tstart = xmalloc(length);\n+\tif(start == NULL) {\n+\t\terrno = ENOMEM;\n+\t\treturn MAP_FAILED;\n+\t}\n+\n+\twhile(n < length) {\n+\t\tint count = read(fd, start+n, length-n);\n+\n+\t\tif(count == 0) {\n+\t\t\tmemset(start+n, 0, length-n);\n+\t\t\tbreak;\n+\t\t}\n+\n+\t\tif(count < 0) {\n+\t\t\tfree(start);\n+\t\t\terrno = EACCES;\n+\t\t\treturn MAP_FAILED;\n+\t\t}\n+\n+\t\tn += count;\n+\t}\n+\n+\treturn start;\n+}\n+\n+int gitfakemunmap(void *start, size_t length)\n+{\n+\tfree(start);\n+\n+\treturn 0;\n+}\n+\ndiff --git a/mailsplit.c b/mailsplit.c\nindex 7981f87..0f8100d 100644\n--- a/mailsplit.c\n+++ b/mailsplit.c\n@@ -9,7 +9,6 @@\n #include \n #include \n #include \n-#include \n #include \n #include \n #include \n---\n0.99.8.GIT\n"},{"id":"9865","messageId":"pan.2005.10.09.20.39.59.765531@smurf.noris.de","threadId":"1969","inReplyTo":"20051007212250.GA1423@steel.home","subject":"Commit text BEFORE the dashes (Re: First cut at git port to Cygwin)","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-10-09T20:40:01Z","receivedAt":"2005-10-09T20:40:01Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Alex Riesen wrote:\n\n> [ some text ]\n> ---\n> [ the actual commit text ]\n\nREMINDER: These need to be swapped.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\n"},{"id":"9902","messageId":"434AB663.8050205@zytor.com","threadId":"1969","inReplyTo":"7vr7avrgr2.fsf@assigned-by-dhcp.cox.net","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-10T18:43:47Z","receivedAt":"2005-10-10T18:43:47Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n> correctly we do not write file via mmap -- at least we do not\n> intend to.\n> \n\nThen PROT_READ probably makes more sense?\n\n> \n> Yes. It might have been overkill that you supported writing\n> changes back, though.\n\nNot just overkill; if we do MAP_PRIVATE it's actively WRONG.\n\n\t-hpa\n"},{"id":"9901","messageId":"434AB6AD.9090107@zytor.com","threadId":"1969","inReplyTo":"20051008010021.GA29261@gentoo.org","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-10T18:45:01Z","receivedAt":"2005-10-10T18:45:01Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Elfyn McBratney wrote:\n> > \n> > Junio, unless there already are pressing reasons to put the patch in\n> > GIT, could you postpone its inclusion (if you ever considered)? Or at\n> > least put \"#ifdef __cygwin\" (I hope this is the define) around it?\n> \n> Close ;) - the define is \"__CYGWIN__\".\n> \n\nThis should be a feature-control macro in the Makefile.\n"},{"id":"9904","messageId":"Pine.LNX.4.63.0510102100010.7688@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"1969","inReplyTo":"434AB663.8050205@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-10T19:01:31Z","receivedAt":"2005-10-10T19:01:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Oct 2005, H. Peter Anvin wrote:\n\n> Junio C Hamano wrote:\n> > \n> > PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n> > correctly we do not write file via mmap -- at least we do not\n> > intend to.\n> > \n> \n> Then PROT_READ probably makes more sense?\n\nNot necessarily. Sometimes you need to annotate the data from the index, \nand this does not need to be written back to the index file.\n\n> > Yes. It might have been overkill that you supported writing\n> > changes back, though.\n> \n> Not just overkill; if we do MAP_PRIVATE it's actively WRONG.\n\nSee above.\n\nBTW, is there a mechanism to make sure that the index file is locked \nbetween reading and writing?\n\nCiao,\nDscho\n"},{"id":"9907","messageId":"434AC058.60803@zytor.com","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0510102100010.7688@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-10T19:26:16Z","receivedAt":"2005-10-10T19:26:16Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Johannes Schindelin wrote:\n> \n>>Junio C Hamano wrote:\n>>\n>>>PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n>>>correctly we do not write file via mmap -- at least we do not\n>>>intend to.\n>>>\n>>\n>>Then PROT_READ probably makes more sense?\n> \n> Not necessarily. Sometimes you need to annotate the data from the index, \n> and this does not need to be written back to the index file.\n> \n\nIn the above sentence, emphasis on \"at least we do not intend to.\" If \nwrites are done legitimately then that's fine, but we shouldn't have \n\"accidental writes\" -- those would be program bugs!\n\n> \n>>>Yes. It might have been overkill that you supported writing\n>>>changes back, though.\n>>\n>>Not just overkill; if we do MAP_PRIVATE it's actively WRONG.\n> \n> See above.\n> \n\nEh? If we MAP_PRIVATE, *and* we (intentionally) write to it, we \n*BETTER* not write anything back.\n\n\t-hpa\n"},{"id":"9909","messageId":"Pine.LNX.4.63.0510102139540.7861@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"1969","inReplyTo":"434AC058.60803@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-10T19:42:49Z","receivedAt":"2005-10-10T19:42:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Oct 2005, H. Peter Anvin wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > > Junio C Hamano wrote:\n> > > \n> > > > PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n> > > > correctly we do not write file via mmap -- at least we do not\n> > > > intend to.\n> > > > \n> > > \n> > > Then PROT_READ probably makes more sense?\n> > \n> > Not necessarily. Sometimes you need to annotate the data from the index, and\n> > this does not need to be written back to the index file.\n> > \n> \n> In the above sentence, emphasis on \"at least we do not intend to.\" If writes\n> are done legitimately then that's fine, but we shouldn't have \"accidental\n> writes\" -- those would be program bugs!\n\nYes, those would be bugs. However, if I understood the man page for mmap() \ncorrectly, then PROT_WRITE && MAP_PRIVATE makes the data copy-on-write, \nwhich means that those bugs would have been found (because the changes \nwould no longer be present when git was called the next time). And I \nchecked: all mmap() calls in git are MAP_PRIVATE.\n\n> > > > Yes. It might have been overkill that you supported writing\n> > > > changes back, though.\n> > > \n> > > Not just overkill; if we do MAP_PRIVATE it's actively WRONG.\n> > \n> > See above.\n> > \n> \n> Eh? If we MAP_PRIVATE, *and* we (intentionally) write to it, we *BETTER* not\n> write anything back.\n\nYes. That was *my* mistake.\n\nCiao,\nDscho\n"},{"id":"9914","messageId":"7vr7at3yyd.fsf@assigned-by-dhcp.cox.net","threadId":"1969","inReplyTo":"434AC058.60803@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-10T20:21:30Z","receivedAt":"2005-10-10T20:21:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Eh? If we MAP_PRIVATE, *and* we (intentionally) write to it, we \n> *BETTER* not write anything back.\n\nCorrect.\n\nIt has already been fixed by Johannes last week and I merged it\nover the weekend if not earlier if I recall correctly.\n"},{"id":"9913","messageId":"Pine.LNX.4.63.0510101620290.23242@iabervon.org","threadId":"1969","inReplyTo":"Pine.LNX.4.63.0510102100010.7688@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: First cut at git port to Cygwin","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-10-10T20:27:46Z","receivedAt":"2005-10-10T20:27:46Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 10 Oct 2005, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 10 Oct 2005, H. Peter Anvin wrote:\n> \n> > Junio C Hamano wrote:\n> > > \n> > > PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n> > > correctly we do not write file via mmap -- at least we do not\n> > > intend to.\n> > > \n> > \n> > Then PROT_READ probably makes more sense?\n> \n> Not necessarily. Sometimes you need to annotate the data from the index, \n> and this does not need to be written back to the index file.\n\nIn fact, it is intentional that we open the file O_RDONLY, and mmap it \nPROT_READ | PROT_WRITE, MAP_PRIVATE. We prepare the next index in the \nmemory where we mapped the old index, but we don't want to change what's \non the disk using the mapping; we write that later to a different file \nusing write().\n\n> > > Yes. It might have been overkill that you supported writing\n> > > changes back, though.\n> > \n> > Not just overkill; if we do MAP_PRIVATE it's actively WRONG.\n> \n> See above.\n> \n> BTW, is there a mechanism to make sure that the index file is locked \n> between reading and writing?\n\nThere's definitely locking; the new file is written to \"(filename).lock\", \nwhich is openned O_CREAT | O_EXCL, and is moved to the destination when \nit's complete. I believe everything that intends to write a new index gets \nthe lock before reading the old index, although I haven't actually \nchecked.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"9916","messageId":"7vhdbp3yd7.fsf@assigned-by-dhcp.cox.net","threadId":"1969","inReplyTo":"434AC058.60803@zytor.com","subject":"Re: First cut at git port to Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-10T20:34:12Z","receivedAt":"2005-10-10T20:34:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n>>>Junio C Hamano wrote:\n>>>\n>>>>PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n>>>>correctly we do not write file via mmap -- at least we do not\n>>>>intend to.\n>>>>\n>\n> In the above sentence, emphasis on \"at least we do not intend to.\" If \n> writes are done legitimately then that's fine, but we shouldn't have \n> \"accidental writes\" -- those would be program bugs!\n\nWhat I meant to say was \"we do not intend to write back the\nchanges by expecting the modification on mapped area are written\nback by mmap() mechanism -- the updates to index file is done by\ncreat - write - close - rename\". So your saying \"the overkill\nbeing actively wrong\" was technically correct, but that wrongly\nwritten data was renamed out anyway and no real harm was done.\n"},{"id":"9927","messageId":"434AD48B.8070305@zytor.com","threadId":"1969","inReplyTo":"7vhdbp3yd7.fsf@assigned-by-dhcp.cox.net","subject":"Re: First cut at git port to Cygwin","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-10T20:52:27Z","receivedAt":"2005-10-10T20:52:27Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n> \n>>>>Junio C Hamano wrote:\n>>>>\n>>>>\n>>>>>PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall\n>>>>>correctly we do not write file via mmap -- at least we do not\n>>>>>intend to.\n>>>>>\n>>\n>>In the above sentence, emphasis on \"at least we do not intend to.\" If \n>>writes are done legitimately then that's fine, but we shouldn't have \n>>\"accidental writes\" -- those would be program bugs!\n> \n> \n> What I meant to say was \"we do not intend to write back the\n> changes by expecting the modification on mapped area are written\n> back by mmap() mechanism -- the updates to index file is done by\n> creat - write - close - rename\". So your saying \"the overkill\n> being actively wrong\" was technically correct, but that wrongly\n> written data was renamed out anyway and no real harm was done.\n\nWell, it broke the atomicity of an operation, which *is* a real problem.\n\nAnyway, malloc+read is a dead ringer for MAP_PRIVATE with PROT_WRITE, so \nthat makes it even easier to mimic.\n\n\t-hpa\n"}]}