{"thread":{"id":"14407","subject":"Should we discuss Windows-related changes on git@vger.kernel.org?","startedAt":"2008-07-11T08:07:28Z","lastAt":"2008-07-12T08:07:15Z","messageCount":21,"participants":["Steffen Prohaska","Johannes Schindelin","Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"82933","messageId":"DDFD7E3B-8401-4EA0-9BBA-C9D8E25998A3@zib.de","threadId":"14407","inReplyTo":null,"subject":"Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-11T08:07:28Z","receivedAt":"2008-07-11T08:07:28Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nI decided to stop queuing changes in 4msysgit.  Instead I'd like to\nbring the diff between Junio's and 4msysgit's master to zero.  This\nseems to be achievable after Junio merged Hannes' MinGW changes.\n\nI think all Windows-related changes to the git code base could be\ndiscussed directly on the main git list and the msysgit list would be\nreserved for the MinGW/MSYS runtime environment and the installer.  I do\nnot expect that Windows-related changes would add too much traffic to\nthe list.  But, even though we have mechanisms to separate the\nplatform-specific code from the main code base (like git-compat-util.h),\nthe Windows-related changes eventually need to be integrated with the\nmainline, so it might make sense to discuss them on the main list right\naway.\n\nWhat do you think?\n\n         Steffen\n"},{"id":"82947","messageId":"alpine.DEB.1.00.0807111349470.3640@eeepc-johanness","threadId":"14407","inReplyTo":"DDFD7E3B-8401-4EA0-9BBA-C9D8E25998A3@zib.de","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-11T11:56:46Z","receivedAt":"2008-07-11T11:56:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Jul 2008, Steffen Prohaska wrote:\n\n> I decided to stop queuing changes in 4msysgit.  Instead I'd like to\n> bring the diff between Junio's and 4msysgit's master to zero.  This\n> seems to be achievable after Junio merged Hannes' MinGW changes.\n> \n> I think all Windows-related changes to the git code base could be\n> discussed directly on the main git list and the msysgit list would be\n> reserved for the MinGW/MSYS runtime environment and the installer.\n\nI disagree.  Judging from the mails I read on the git list, Junio gets \nreally swamped by patches these days (what with our very productive GSoC \nstudents).\n\nI really think that we should discuss the patches on the msysGit list \nfirst, whip them into shape, and then send them off.\n\nJust think of those patches that were sent off, only to realize that they \nwere no longer needed.  That should not have happened.\n\nMy 2p,\nDscho\n"},{"id":"82970","messageId":"65365AC4-D7C9-462B-8239-F3B35F7ECBEF@zib.de","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807111349470.3640@eeepc-johanness","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-11T15:51:15Z","receivedAt":"2008-07-11T15:51:15Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\n\nOn Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:\n\n> On Fri, 11 Jul 2008, Steffen Prohaska wrote:\n>\n>> I decided to stop queuing changes in 4msysgit.  Instead I'd like to\n>> bring the diff between Junio's and 4msysgit's master to zero.  This\n>> seems to be achievable after Junio merged Hannes' MinGW changes.\n>>\n>> I think all Windows-related changes to the git code base could be\n>> discussed directly on the main git list and the msysgit list would be\n>> reserved for the MinGW/MSYS runtime environment and the installer.\n>\n> I disagree.  Judging from the mails I read on the git list, Junio gets\n> really swamped by patches these days (what with our very productive  \n> GSoC\n> students).\n\nSending the patches to the git list does not necessarily mean that\nthey are directly addressed to Junio.  We discuss JGIT, EGIT, gitk,\nand git gui patches on the list too.  AFAIK, none of them are applied\nby Junio directly but by the respective maintainers.  We could handle\nWindows-related patches similarly.\n\n\n> I really think that we should discuss the patches on the msysGit list\n> first, whip them into shape, and then send them off.\n>\n> Just think of those patches that were sent off, only to realize that  \n> they\n> were no longer needed.  That should not have happened.\n\n\nI intentionally sent the patches to show and discuss the differences\nbetween the state of the MinGW port in Junio's master and in 4msysgit.\nSome of the patches could be reverted in 4msysgit.  But, at least one\npatch was unrelated to MinGW and is now in master.  Some other patches\nneed more work and are currently improved.  I think this was not a waste\nof time.\n\n\tSteffen\n"},{"id":"82972","messageId":"alpine.DEB.1.00.0807111652170.8950@racer","threadId":"14407","inReplyTo":"65365AC4-D7C9-462B-8239-F3B35F7ECBEF@zib.de","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-11T15:57:04Z","receivedAt":"2008-07-11T15:57:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Jul 2008, Steffen Prohaska wrote:\n\n> On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:\n> \n> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:\n> >\n> > >I decided to stop queuing changes in 4msysgit.  Instead I'd like to\n> > >bring the diff between Junio's and 4msysgit's master to zero.  This\n> > >seems to be achievable after Junio merged Hannes' MinGW changes.\n> > >\n> > >I think all Windows-related changes to the git code base could be\n> > >discussed directly on the main git list and the msysgit list would be\n> > >reserved for the MinGW/MSYS runtime environment and the installer.\n> >\n> >I disagree.  Judging from the mails I read on the git list, Junio gets\n> >really swamped by patches these days (what with our very productive GSoC\n> >students).\n> \n> Sending the patches to the git list does not necessarily mean that\n> they are directly addressed to Junio.  We discuss JGIT, EGIT, gitk,\n> and git gui patches on the list too.  AFAIK, none of them are applied\n> by Junio directly but by the respective maintainers.  We could handle\n> Windows-related patches similarly.\n\nThen what is the msysGit list about?\n\nNo, I really disagree.  Windows support is too large a thing, and partly a \ntoo disgusting one to bother the git list.\n\n> >I really think that we should discuss the patches on the msysGit list \n> >first, whip them into shape, and then send them off.\n> >\n> >Just think of those patches that were sent off, only to realize that \n> >they were no longer needed.  That should not have happened.\n> \n> I intentionally sent the patches to show and discuss the differences \n> between the state of the MinGW port in Junio's master and in 4msysgit. \n> Some of the patches could be reverted in 4msysgit.  But, at least one \n> patch was unrelated to MinGW and is now in master.  Some other patches \n> need more work and are currently improved.  I think this was not a waste \n> of time.\n\nIMO we could have discussed first what is the current state on the msysGit \nlist, and I would have commented there already on the patches that I think \nwould no longer be needed.\n\nThen the patch would have been sent off, and be in master, too.\n\nThe difference: it would have been more efficient.  Those people who can \ntest if something is still needed on Windows are on the msysGit list.\n\nWe do not really need to clutter git@vger more than necessary.\n\nCiao,\nDscho\n"},{"id":"82979","messageId":"A065AF71-5685-423A-9F87-5349ADC6C9C9@zib.de","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807111652170.8950@racer","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-11T16:24:16Z","receivedAt":"2008-07-11T16:24:16Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\n\nOn Jul 11, 2008, at 5:57 PM, Johannes Schindelin wrote:\n\n> On Fri, 11 Jul 2008, Steffen Prohaska wrote:\n>\n>> On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:\n>>\n>>> On Fri, 11 Jul 2008, Steffen Prohaska wrote:\n>>>\n>>>> I decided to stop queuing changes in 4msysgit.  Instead I'd like to\n>>>> bring the diff between Junio's and 4msysgit's master to zero.  This\n>>>> seems to be achievable after Junio merged Hannes' MinGW changes.\n>>>>\n>>>> I think all Windows-related changes to the git code base could be\n>>>> discussed directly on the main git list and the msysgit list  \n>>>> would be\n>>>> reserved for the MinGW/MSYS runtime environment and the installer.\n>>>\n>>> I disagree.  Judging from the mails I read on the git list, Junio  \n>>> gets\n>>> really swamped by patches these days (what with our very  \n>>> productive GSoC\n>>> students).\n>>\n>> Sending the patches to the git list does not necessarily mean that\n>> they are directly addressed to Junio.  We discuss JGIT, EGIT, gitk,\n>> and git gui patches on the list too.  AFAIK, none of them are applied\n>> by Junio directly but by the respective maintainers.  We could handle\n>> Windows-related patches similarly.\n>\n> Then what is the msysGit list about?\n\nI think the msysGit list could be useful for:\n\n  - Everything that is in the msysgit repo, i.e. the MinGW/MSYS\n    runtime environment and the installers.\n\n  - User questions, including the issue tracker.\n\n\n> No, I really disagree.  Windows support is too large a thing, and  \n> partly a\n> too disgusting one to bother the git list.\n\nMy understanding is that the mainline of git starts supporting the MinGW\nport with version 1.6.0.  The MinGW port is merged to Junio's master, so\nthe remaining differences between Junio's master and 4msysgit's master\nshould be removed and afterwards new changes should be discussed,  \nimproved,\nand applied to Junio's master anyway.  This would also allow to directly\ntest Junio's next on Windows.\n\n\n>>> I really think that we should discuss the patches on the msysGit  \n>>> list\n>>> first, whip them into shape, and then send them off.\n>>>\n>>> Just think of those patches that were sent off, only to realize that\n>>> they were no longer needed.  That should not have happened.\n>>\n>> I intentionally sent the patches to show and discuss the differences\n>> between the state of the MinGW port in Junio's master and in  \n>> 4msysgit.\n>> Some of the patches could be reverted in 4msysgit.  But, at least one\n>> patch was unrelated to MinGW and is now in master.  Some other  \n>> patches\n>> need more work and are currently improved.  I think this was not a  \n>> waste\n>> of time.\n>\n> IMO we could have discussed first what is the current state on the  \n> msysGit\n> list, and I would have commented there already on the patches that I  \n> think\n> would no longer be needed.\n>\n> Then the patch would have been sent off, and be in master, too.\n>\n> The difference: it would have been more efficient.  Those people who  \n> can\n> test if something is still needed on Windows are on the msysGit list.\n>\n> We do not really need to clutter git@vger more than necessary.\n\nBut git 1.6 will contain the MinGW port.  Shouldn't related patches\nthen be discussed on git@vger?\n\n\tSteffen\n"},{"id":"82989","messageId":"alpine.DEB.1.00.0807111930160.8950@racer","threadId":"14407","inReplyTo":"A065AF71-5685-423A-9F87-5349ADC6C9C9@zib.de","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-11T18:36:39Z","receivedAt":"2008-07-11T18:36:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Jul 2008, Steffen Prohaska wrote:\n\n> On Jul 11, 2008, at 5:57 PM, Johannes Schindelin wrote:\n> \n> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:\n> >\n> > >On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:\n> > >\n> > > >On Fri, 11 Jul 2008, Steffen Prohaska wrote:\n> > > >\n> > > > >I decided to stop queuing changes in 4msysgit.  Instead I'd like \n> > > > >to bring the diff between Junio's and 4msysgit's master to zero.  \n> > > > >This seems to be achievable after Junio merged Hannes' MinGW \n> > > > >changes.\n> > > > >\n> > > > >I think all Windows-related changes to the git code base could be \n> > > > >discussed directly on the main git list and the msysgit list \n> > > > >would be reserved for the MinGW/MSYS runtime environment and the \n> > > > >installer.\n> > > >\n> > > >I disagree.  Judging from the mails I read on the git list, Junio \n> > > >gets really swamped by patches these days (what with our very \n> > > >productive GSoC students).\n> > >\n> > >Sending the patches to the git list does not necessarily mean that \n> > >they are directly addressed to Junio.  We discuss JGIT, EGIT, gitk, \n> > >and git gui patches on the list too.  AFAIK, none of them are applied \n> > >by Junio directly but by the respective maintainers.  We could handle \n> > >Windows-related patches similarly.\n> >\n> >Then what is the msysGit list about?\n> \n> I think the msysGit list could be useful for:\n> \n> - Everything that is in the msysgit repo, i.e. the MinGW/MSYS\n>   runtime environment and the installers.\n\nWhich very much includes brushing up the patches in 4msysgit, which are \ninvariably of lower quality than git.git's, because we lack a brilliant \nmaintainer like Junio.\n\nCome to think of it, we do not have a maintainer at all.  Many people can \ncommit and push into 4msysgit, and I am debating with myself for a long \ntime already if that was a sensible thing to do.  Just think of that C# \ndesaster.\n\n> >No, I really disagree.  Windows support is too large a thing, and \n> >partly a too disgusting one to bother the git list.\n> \n> My understanding is that the mainline of git starts supporting the MinGW \n> port with version 1.6.0.  The MinGW port is merged to Junio's master, so \n> the remaining differences between Junio's master and 4msysgit's master \n> should be removed and afterwards new changes should be discussed, \n> improved, and applied to Junio's master anyway.  This would also allow \n> to directly test Junio's next on Windows.\n\nJunio expressed several times that he is uncomfortable that he cannot \neasily test Windows support himself.\n\nI strongly doubt that discussing things on git@vger that are not even \nhalf-cooked would help that impression.\n\nAlso, there are a lot of people on git@vger who could not care _less_ \nabout Windows.\n\nAnd there are a few on the list who could not care less about those \nWindows users who seem to be content to let others work for them, but \ncomment at every _possible_ occasion, on what should, and what should not \nbe done.  Let's keep them on the msysGit list, for the benefit of the \nsaner half of git@vger.\n\n> > > >I really think that we should discuss the patches on the msysGit \n> > > >list first, whip them into shape, and then send them off.\n> > > >\n> > > >Just think of those patches that were sent off, only to realize \n> > > >that they were no longer needed.  That should not have happened.\n> > >\n> > >I intentionally sent the patches to show and discuss the differences \n> > >between the state of the MinGW port in Junio's master and in \n> > >4msysgit. Some of the patches could be reverted in 4msysgit.  But, at \n> > >least one patch was unrelated to MinGW and is now in master.  Some \n> > >other patches need more work and are currently improved.  I think \n> > >this was not a waste of time.\n> >\n> >IMO we could have discussed first what is the current state on the \n> >msysGit list, and I would have commented there already on the patches \n> >that I think would no longer be needed.\n> >\n> >Then the patch would have been sent off, and be in master, too.\n> >\n> >The difference: it would have been more efficient.  Those people who \n> >can test if something is still needed on Windows are on the msysGit \n> >list.\n> >\n> >We do not really need to clutter git@vger more than necessary.\n> \n> But git 1.6 will contain the MinGW port.  Shouldn't related patches then \n> be discussed on git@vger?\n\nSee above.  There will be a rudimentary support for MinGW, yes, but that's \nfor hardcore people like Hannes.\n\nFor those who just want to use Git on Windows, there is msysGit.  And \nfor them, we have the msysGit list.\n\nLet's not confuse things, let's not upset git@vger with too many less \nclueful users who should rather post to msysgit@googlegroups.com.\n\nCiao,\nDscho\n"},{"id":"82998","messageId":"alpine.LFD.1.10.0807111159560.2936@woody.linux-foundation.org","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807111930160.8950@racer","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-11T19:04:24Z","receivedAt":"2008-07-11T19:04:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\n\nOn Fri, 11 Jul 2008, Johannes Schindelin wrote:\n> \n> Which very much includes brushing up the patches in 4msysgit, which are \n> invariably of lower quality than git.git's, because we lack a brilliant \n> maintainer like Junio.\n\nUmm. The other side of the coin is:\n\n - a lot of people with good taste won't _be_ on the windows lists, \n   because there is likely a high correlation with \"good taste in \n   development\" and \"try to avoid using windows\"\n\n - a lot of Junio's maintenance is likely helped by the fact that (a) he \n   sees the features being discussed and the reason for them and (b) the \n   patches have in general seen comments from other people.\n\n - It may well be good to explain to the _real_ git people (eg me) what \n   the problems in Windows land are, so that we get a first-hand view into \n   hell, and can maybe take it into account when we make changes for other \n   things.\n\nIOW, I think that since 1.6.0 is supposed to have native support for \nwindows, we should have patches discussed on the regular git list. The \nghetto that is windows can be useful for _user_ discussions, where a lot \nof the core git people simply cannot help. But having development \ndiscussions there is bad, I think.\n\n\t\tLinus\n"},{"id":"83001","messageId":"alpine.DEB.1.00.0807112037220.8950@racer","threadId":"14407","inReplyTo":"alpine.LFD.1.10.0807111159560.2936@woody.linux-foundation.org","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-11T19:40:46Z","receivedAt":"2008-07-11T19:40:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nHi,\n\nOn Fri, 11 Jul 2008, Linus Torvalds wrote:\n\n>  - It may well be good to explain to the _real_ git people (eg me) what \n>    the problems in Windows land are, so that we get a first-hand view \n>    into hell, and can maybe take it into account when we make changes \n>    for other things.\n\nWow.  I did not think that you were a masochist.\n\n> IOW, I think that since 1.6.0 is supposed to have native support for \n> windows, we should have patches discussed on the regular git list. The \n> ghetto that is windows can be useful for _user_ discussions, where a lot \n> of the core git people simply cannot help. But having development \n> discussions there is bad, I think.\n\nWe do have development discussions there that do not belong to git@vger.  \nFor example, when Hannes reimplemented the utterly broken spawn() \nimplementation of Microsoft's \"Run\" time library.\n\nThat is not something you need to see, want to see, or can help with.\n\nLikewise, I think it has nothing to do with the git@vger list when we add \nwork-arounds until some better solution is found, and then discuss whether \nthe workaround is still needed.\n\nI cannot help to see the benefit, at least.\n\nOnce things are sorted out, I agree, it has to be sent to the git list.\n\nBefore that, however, allow us to work on another list.\n\nCiao,\nDscho\n"},{"id":"83013","messageId":"0E93411E-745C-4858-999E-F0B7487B48B1@zib.de","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807112037220.8950@racer","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-11T21:10:12Z","receivedAt":"2008-07-11T21:10:12Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\n\nOn Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote:\n\n> On Fri, 11 Jul 2008, Linus Torvalds wrote:\n>\n>> - It may well be good to explain to the _real_ git people (eg me)  \n>> what\n>>   the problems in Windows land are, so that we get a first-hand view\n>>   into hell, and can maybe take it into account when we make changes\n>>   for other things.\n>\n> Wow.  I did not think that you were a masochist.\n>\n>> IOW, I think that since 1.6.0 is supposed to have native support for\n>> windows, we should have patches discussed on the regular git list.  \n>> The\n>> ghetto that is windows can be useful for _user_ discussions, where  \n>> a lot\n>> of the core git people simply cannot help. But having development\n>> discussions there is bad, I think.\n>\n> We do have development discussions there that do not belong to  \n> git@vger.\n> For example, when Hannes reimplemented the utterly broken spawn()\n> implementation of Microsoft's \"Run\" time library.\n>\n> That is not something you need to see, want to see, or can help with.\n\nThe separation is not always that clear.  For example, the discussion\nof issue 130 might benefit from \"a first-hand view into hell\", see\n\nhttp://thread.gmane.org/gmane.comp.version-control.msysgit/2653/focus=2682\n\n\nAnother example is the discussion about GIT_EXEC_PATH, see\n\nhttp://thread.gmane.org/gmane.comp.version-control.msysgit/2633\n\nIt might be triggered by msysGit's need to freely move a git  \ninstallation\nin the filesystem.  The resulting feature might however be interesting  \non\nother platforms, too.\n\n\nA last example is the crash of gitk that was observed on Windows and is\nnow buried in the msysGit issue tracker, although I am pretty sure that\nis it not windows-specific, see\n\nhttp://code.google.com/p/msysgit/issues/detail?id=125\n\n\n\n> Likewise, I think it has nothing to do with the git@vger list when  \n> we add\n> work-arounds until some better solution is found, and then discuss  \n> whether\n> the workaround is still needed.\n>\n> I cannot help to see the benefit, at least.\n>\n> Once things are sorted out, I agree, it has to be sent to the git  \n> list.\n>\n> Before that, however, allow us to work on another list.\n\nPersonally, I'd find it easier to work on a single list.  MinGW support\nis mature enough and workarounds should now be avoid.  If we tested git\nduring the official release cycle, we would have sufficient time to find\nand solve problems on Windows and prepare patches that have sufficient\nquality to be discuss on git@vger.\n\n\tSteffen\n"},{"id":"83017","messageId":"alpine.DEB.1.00.0807112226190.8950@racer","threadId":"14407","inReplyTo":"0E93411E-745C-4858-999E-F0B7487B48B1@zib.de","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-11T21:38:23Z","receivedAt":"2008-07-11T21:38:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Jul 2008, Steffen Prohaska wrote:\n\n> On Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote:\n> \n> >On Fri, 11 Jul 2008, Linus Torvalds wrote:\n> >\n> > >- It may well be good to explain to the _real_ git people (eg me) \n> > >  what the problems in Windows land are, so that we get a first-hand \n> > >  view into hell, and can maybe take it into account when we make \n> > >  changes for other things.\n> >\n> >Wow.  I did not think that you were a masochist.\n> >\n> > >IOW, I think that since 1.6.0 is supposed to have native support for \n> > >windows, we should have patches discussed on the regular git list. \n> > >The ghetto that is windows can be useful for _user_ discussions, \n> > >where a lot of the core git people simply cannot help. But having \n> > >development discussions there is bad, I think.\n> >\n> >We do have development discussions there that do not belong to \n> >git@vger. For example, when Hannes reimplemented the utterly broken \n> >spawn() implementation of Microsoft's \"Run\" time library.\n> >\n> >That is not something you need to see, want to see, or can help with.\n> \n> The separation is not always that clear.  For example, the discussion\n> of issue 130 might benefit from \"a first-hand view into hell\",\n\nMaybe I am overly cautious, but you remember what drove me away from \nmsysGit?  Exactly, people, and issues, took out all the fun.\n\nLet's not inflict upon git@vger what they did not deserve to suffer.\n\nAnd if the separation is not always that clear, why not discuss those \nthings on msysGit first, and then come to git@vger with our minds (and \npossibly our patches) made up?\n\n> Another example is the discussion about GIT_EXEC_PATH, see\n> \n> http://thread.gmane.org/gmane.comp.version-control.msysgit/2633\n\nThis is a particularly good example that does not matter for Linux, \nMacOSX, Solaris or the BSDs (Git's principal platforms!) at all.\n\nAnd once this patch hits git@vger, it is still visible to other platforms.\n\n> A last example is the crash of gitk that was observed on Windows and is \n> now buried in the msysGit issue tracker, although I am pretty sure that \n> is it not windows-specific, see\n> \n> http://code.google.com/p/msysgit/issues/detail?id=125\n\nSo?  If it did not hit other platforms, it is the duty of that guy to find \nout what it is.  And if it _does_ turn out to be a Windows-specific bug, \nwhich might very well be the case, we do not need to add to the volume of \ngit@vger.\n\n> >Likewise, I think it has nothing to do with the git@vger list when we \n> >add work-arounds until some better solution is found, and then discuss \n> >whether the workaround is still needed.\n> >\n> >I cannot help to see the benefit, at least.\n> >\n> >Once things are sorted out, I agree, it has to be sent to the git list.\n> >\n> >Before that, however, allow us to work on another list.\n> \n> Personally, I'd find it easier to work on a single list.\n\nSure the benefit is undisputed.\n\nNow let's look at the downsides: we take away time, and possibly fun, from \nmany more people than one or two persons.\n\nIt's like spam.  Asking somebody to \"just hit the delete button\" stops \nbeing funny very quickly.\n\n> MinGW support is mature enough and workarounds should now be avoid.  If \n> we tested git during the official release cycle, we would have \n> sufficient time to find and solve problems on Windows and prepare \n> patches that have sufficient quality to be discuss on git@vger.\n\nI am not so sure.\n\nYour experience should match mine, that the patches coming in through \nmsysGit are of a substantial lower quality than what we are used to on \ngit@vger.\n\nIf you want to force those patches unfiltered onto the readers of \ngit@vger, it would only be fair that you have to clean the readers' latest \nlunch out of their keyboards.\n\nCiao,\nDscho \"who has a fata morgana of windmills\"\n"},{"id":"83029","messageId":"7v4p6wjcgm.fsf@gitster.siamese.dyndns.org","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807112037220.8950@racer","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-11T22:14:01Z","receivedAt":"2008-07-11T22:14:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Fri, 11 Jul 2008, Linus Torvalds wrote:\n>\n>>  - It may well be good to explain to the _real_ git people (eg me) what \n>>    the problems in Windows land are, so that we get a first-hand view \n>>    into hell, and can maybe take it into account when we make changes \n>>    for other things.\n>\n> Wow.  I did not think that you were a masochist.\n\nIt is not being masochist, but being practical by trying to know what to\navoid in advance.\n\n>> IOW, I think that since 1.6.0 is supposed to have native support for \n>> windows, we should have patches discussed on the regular git list. The \n>> ghetto that is windows can be useful for _user_ discussions, where a lot \n>> of the core git people simply cannot help. But having development \n>> discussions there is bad, I think.\n>\n> We do have development discussions there that do not belong to git@vger.  \n\nHannes did a great job with help from msysGit people to contain platform\nspecific stuff in compat/ layer.  A good rule of thumb to decide what not\nto talk about here is:\n\n - If it is purely about implementation inside compat/ layer, such as\n   creating spawn() using Windows specific API, it is probably better done\n   on the msysGit list, where presumably more people whose has expertise\n   on the particular platform would hang around;\n\n - If it is about \"I downloaded msysgit prepackaged binary and this and\n   that does not work as I expect, I haven't bothered trying to build it\n   from source on POSIX systems and see if it is broken in the upstream\",\n   the RFH does not belong here but platform specific forum.  This applies\n   not just to Windows but to various distro binary distributions on Linux\n   as well.\n\nOn the other hand, even if it is related to porting to Windows, discussing\nwhat the compat/ abstraction should look like is very relevant to this\nlist.\n\nFor example, I like is_absolute_path() abstraction you and Hannes pushed\nfor, but I have a slight distaste against has_dos_drive_prefix().  Some\nuses of that macro is about telling if a string is a local file pathname\n(e.g. connect()), and some other uses of that macro is about the fact that\non Windows you cannot necessarily make one path relative to another but\nour code largely assume that any path can be made relative to any other\npath (i.e. on traditional UNIX without \"//\", you can always make a path\nrelative by prefixing enough number of \"../\" to go up, even to root if\nneeded, but you cannot make C:\\foo relative to D:\\bar).  We may be able to\nfind a better abstraction than what has_dos_drive_prefix() offers, and I\nthink that discussion belongs to here.\n\nAnother example that has already happened was our move away from direct\nuse of fork/exec but abstracting it out to run_command() layer.  This\nwould not have settled in a shape usable by both Windows and POSIX if\npeople from both camps did not participate in the design and review.\n"},{"id":"83035","messageId":"7vmykohvfy.fsf@gitster.siamese.dyndns.org","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807112226190.8950@racer","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-11T23:06:57Z","receivedAt":"2008-07-11T23:06:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> And if the separation is not always that clear, why not discuss those \n> things on msysGit first, and then come to git@vger with our minds (and \n> possibly our patches) made up?\n\nI know you mean well, but my impression from reading the kernel list is\nthat often a message that says \"we already debated this issue on our list\nto death and here is our conclusion, take it or leave it\" to the audience\nis not accepted warmly, and more central kernel people may even say \"do\nnot hide the discussion in the subsystem list, do it in the open,\ndiscussion on the subsystem list does not matter\".\n\nTaking that lesson from the other community, I'd suggest that it is\nprobably a good idea to start discussion on your list, but once (some)\npeople in the discussion think the topic is releavant here, move it here\nsooner rather than later.\n"},{"id":"83039","messageId":"alpine.DEB.1.00.0807120033490.8950@racer","threadId":"14407","inReplyTo":"7v4p6wjcgm.fsf@gitster.siamese.dyndns.org","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-11T23:35:20Z","receivedAt":"2008-07-11T23:35:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nHi,\n\nOn Fri, 11 Jul 2008, Junio C Hamano wrote:\n\n> Another example that has already happened was our move away from direct \n> use of fork/exec but abstracting it out to run_command() layer.  This \n> would not have settled in a shape usable by both Windows and POSIX if \n> people from both camps did not participate in the design and review.\n\nI think that is a perfect example, since Hannes worked on it in mingw.git.  \nAFAIR a few comments came through msysGit, and were incorporated.  When \neverything was good for a first go at git@vger, it was sent, and the \ninterface finalized.\n\nAnd I agree that it is a pretty beautiful interface.\n\nCiao,\nDscho\n"},{"id":"83040","messageId":"alpine.DEB.1.00.0807120036090.8950@racer","threadId":"14407","inReplyTo":"7vmykohvfy.fsf@gitster.siamese.dyndns.org","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-11T23:37:50Z","receivedAt":"2008-07-11T23:37:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > And if the separation is not always that clear, why not discuss those \n> > things on msysGit first, and then come to git@vger with our minds (and \n> > possibly our patches) made up?\n> \n> I know you mean well, but my impression from reading the kernel list is \n> that often a message that says \"we already debated this issue on our \n> list to death and here is our conclusion, take it or leave it\" to the \n> audience is not accepted warmly, and more central kernel people may even \n> say \"do not hide the discussion in the subsystem list, do it in the \n> open, discussion on the subsystem list does not matter\".\n\nI never meant on insisting that we find the final solution on the msysGit \nlist, and I would _never_ suggest that anything sent to git@vger is final.  \nIt is always subject to discussion.\n\nAnyway, enough said (since I think that you and me are in agreement here),\nDscho\n"},{"id":"83042","messageId":"alpine.LFD.1.10.0807111638130.3459@woody.linux-foundation.org","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807120033490.8950@racer","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-11T23:40:45Z","receivedAt":"2008-07-11T23:40:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\n\nOn Sat, 12 Jul 2008, Johannes Schindelin wrote:\n> \n> I think that is a perfect example, since Hannes worked on it in mingw.git.  \n> AFAIR a few comments came through msysGit, and were incorporated.  When \n> everything was good for a first go at git@vger, it was sent, and the \n> interface finalized.\n\nUmm. Dscho - that was before the thing was merged.\n\nNow that the basic mingw support is part of standard git, the situation \nhas changed.\n\nThat's the main issue here - if mingw support is in standard git (and it \nis), then mingw issues that touch any non-mingw code should be discussed \nwhere all the git developers are.\n\nCan't you see the difference between the pre-merge and the post-merge \nsituation?\n\n\t\tLinus\n"},{"id":"83045","messageId":"alpine.DEB.1.00.0807120043150.8950@racer","threadId":"14407","inReplyTo":"alpine.LFD.1.10.0807111638130.3459@woody.linux-foundation.org","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-11T23:47:37Z","receivedAt":"2008-07-11T23:47:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Jul 2008, Linus Torvalds wrote:\n\n> On Sat, 12 Jul 2008, Johannes Schindelin wrote:\n> > \n> > I think that is a perfect example, since Hannes worked on it in \n> > mingw.git.  AFAIR a few comments came through msysGit, and were \n> > incorporated.  When everything was good for a first go at git@vger, it \n> > was sent, and the interface finalized.\n> \n> Umm. Dscho - that was before the thing was merged.\n> \n> Now that the basic mingw support is part of standard git, the situation \n> has changed.\n> \n> That's the main issue here - if mingw support is in standard git (and it \n> is), then mingw issues that touch any non-mingw code should be discussed \n> where all the git developers are.\n> \n> Can't you see the difference between the pre-merge and the post-merge \n> situation?\n\nSure I can.\n\nBut we are talking about 4msysgit.git, no?\n\nAt least the patches that Steffen sent were all from 4msysgit.git, and for \nsome reason or other not necessary for Hannes' mingw.git.\n\nWe are talking about stuff like that putty thing, where people feel it \nwould be a better idea to avoid scripts, at the cost of a higher \nmaintenance burden.\n\nWe are talking about patches that were necessary a long time ago, but are \nno longer, and we should have that sorted out on the msysGit list before \nsending them to a list where many people could not care less for Windows, \nand are probably annoyed to even read as much as _this_ thread about it, \nlet alone be bothered by patches that turn out to be stale in the first \nplace.\n\n_That_ is what I am arguing should be sorted out, at least the early \nstages, on msysGit.  As we did in the past.\n\nAnd that worked out rather well so far, do you disagree?\n\nCiao,\nDscho\n"},{"id":"83046","messageId":"alpine.LFD.1.10.0807111653500.2875@woody.linux-foundation.org","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807120043150.8950@racer","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-11T23:58:28Z","receivedAt":"2008-07-11T23:58:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\n\nOn Sat, 12 Jul 2008, Johannes Schindelin wrote:\n> \n> But we are talking about 4msysgit.git, no?\n\nI'm not. I'm just talking about Windows-related changes in git in \ngeneral, that are expected to be merged into regular git one way or \nanother.\n\nIf it's something that should be merged, and if it concerns code that I'm \ninterested in, I want to know about it. It's that simple.\n\nThe fact that _all_ windows discussion used to be in a different area and \nnot on the -git list is past. It was definitely the case that it didn't \naffect any normal git code, since it was all maintained in a separate tree \nand the normal git tree was simply not even _relevant_, and didn't even \ntry to be.\n\nBut that's changed. I think the windows support merge was really quite \nwell done, and was a rather clean series, and no, I don't think the unix \npeople cared about it when there was so much fundamental stuff needed to \nbe done - we didn't have any relevant input.\n\nBut I'd certainly _hope_ that future windows work is incremental, and at \nthat point it's no longer a \"drop the end result on people\" situation.\n\n\t\tLinus\n"},{"id":"83047","messageId":"alpine.DEB.1.00.0807120104460.8950@racer","threadId":"14407","inReplyTo":"alpine.LFD.1.10.0807111653500.2875@woody.linux-foundation.org","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-12T00:06:04Z","receivedAt":"2008-07-12T00:06:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Jul 2008, Linus Torvalds wrote:\n\n> On Sat, 12 Jul 2008, Johannes Schindelin wrote:\n> > \n> > But we are talking about 4msysgit.git, no?\n> \n> I'm not. I'm just talking about Windows-related changes in git in \n> general, that are expected to be merged into regular git one way or \n> another.\n>\n> [...]\n> \n> But I'd certainly _hope_ that future windows work is incremental, and at \n> that point it's no longer a \"drop the end result on people\" situation.\n\nFair enough.  You'll get all the crap now, I expect.\n\nSeriously again, I really hope that things do not change very much.  Even \nif the occasional patch will now come in directly to git@vger.\n\nCiao,\nDscho\n"},{"id":"83050","messageId":"alpine.LFD.1.10.0807111750200.2875@woody.linux-foundation.org","threadId":"14407","inReplyTo":"alpine.LFD.1.10.0807111653500.2875@woody.linux-foundation.org","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-12T01:07:34Z","receivedAt":"2008-07-12T01:07:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\n\nOn Fri, 11 Jul 2008, Linus Torvalds wrote:\n> \n> If it's something that should be merged, and if it concerns code that I'm \n> interested in, I want to know about it. It's that simple.\n\nBtw, an example of where I think we need to look at both windows and unix \nbehavior and not try to make them two different camps is in that\n\"start_command()\" thing.\n\nIt was changed to have a totally separate __MINGW32__ part, but the thing \nis, the unix side could really be improved - and actually made more like \nthe MINGW32 code at the same time!\n\nFor example, on many systems it is rather noticeably faster to use \n\"vfork+execve\" than it is to do \"fork+execve\", because you avoid a whole \n\"duplicate and tear down page tables\" sequence. So the UNIX code would \nactually be better off using \"vfork()\" instead of \"fork()\" there.\n\nBut it can't right now - because if \"cmd->env\" changes the environment, it \nwould change it both in the caller and in the result.\n\nIt turns out that Windows has the exact same issue (because it uses a \nspawn thing), and already does a \"copy_env() + change-in-copy + free\" \nmodel for that reason.\n\nIf that was shared, the UNIX side could just use vfork, I believe. In \nfact, the following trivial - but horribly ugly - patch passes all the \ntests, by doing the vfork() in all cases except when the environment \nchanges. But I don't know what coverage that has, though (maybe env is \neffectively always set?).\n\nAnd I suspect there are other cases where we'd actually be better off \ntrying to share things than having all the differences hidden away in \ncompat layers.\n\n\t\t\tLinus\n\n---\n builtin-grep.c |    2 +-\n run-command.c  |    2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-grep.c b/builtin-grep.c\nindex ef29910..5d3053a 100644\n--- a/builtin-grep.c\n+++ b/builtin-grep.c\n@@ -168,7 +168,7 @@ static int exec_grep(int argc, const char **argv)\n \tint status;\n \n \targv[argc] = NULL;\n-\tpid = fork();\n+\tpid = vfork();\n \tif (pid < 0)\n \t\treturn pid;\n \tif (!pid) {\ndiff --git a/run-command.c b/run-command.c\nindex 6e29fdf..200ba7b 100644\n--- a/run-command.c\n+++ b/run-command.c\n@@ -68,7 +68,7 @@ int start_command(struct child_process *cmd)\n \ttrace_argv_printf(cmd->argv, \"trace: run_command:\");\n \n #ifndef __MINGW32__\n-\tcmd->pid = fork();\n+\tcmd->pid = cmd->env ? fork() : vfork();\n \tif (!cmd->pid) {\n \t\tif (cmd->no_stdin)\n \t\t\tdup_devnull(0);\n"},{"id":"83062","messageId":"B3761FA2-6313-421B-B47F-E03A258DEB6F@zib.de","threadId":"14407","inReplyTo":"alpine.LFD.1.10.0807111653500.2875@woody.linux-foundation.org","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-12T07:38:42Z","receivedAt":"2008-07-12T07:38:42Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\n\nOn Jul 12, 2008, at 1:58 AM, Linus Torvalds wrote:\n\n> On Sat, 12 Jul 2008, Johannes Schindelin wrote:\n>>\n>> But we are talking about 4msysgit.git, no?\n>\n> I'm not. I'm just talking about Windows-related changes in git in\n> general, that are expected to be merged into regular git one way or\n> another.\n\nThe discussion is not about 4msysgit, because 4msysgit will no longer\nbe needed after we cleaned up all differences between Junio's master\nand 4msysgit's master.\n\nI propose the following steps:\n\n  - We review the differences and either prepare patches for official  \ngit\n    or revert commits in 4msysgit.\n    -> It will no longer matter if we build the msysgit release from\n    Junio's master or from 4msysgit's master.\n\n  - We change the /git submodule in msysgit to point to Junio's repo.\n    -> Every developer on Windows will work with the official code base.\n\n  - Windows-users can (and should) participate in the official release\n    cycle.  They should test the next branch and the master branch after\n    the merge window closed.  We can easily create installers for  \nJunio's\n    release candidates (I will do this).\n\nWe should provide a guideline how developers and users should send\ncomments and improvements related to Windows.  Such a guideline could be\nincluded in Junio's \"A note from the maintainer\" mail.  The section on\nWindows needs to be changed anyway.  Currently it says:\n\n'''\n- Johannes Schindelin and Johannes Sixt for their effort to\n   move things forward on the Windows front.  Although my\n   repository does not have much from the effort of MinGW team,\n   I expect a merge into mainline will happen so that everybody\n   can work from the same codebase.\n'''\n\n[ Note that the last sentence will become true if we do what I propose\n   above. ]\n\nWe could send more detailed guidelines to the msysgit list and/or modify\nthe homepage of the msysgit project.  I think Junio's rule of thumb in\n\n   http://article.gmane.org/gmane.comp.version-control.git/88191\n\nis a good starting point.\n\nIt would be good to achieve all this during the 1.6 cycle, because\nMinGW is officially part of 1.6.  I am however not sure if it is\npractical.  We have some changes in 4msysgit that might need more\ndiscussion and we did not even start discussing the tests.  So maybe\n1.6.1 is more realistic.\n\n\tSteffen\n"},{"id":"83064","messageId":"03AA6CC0-B64C-4FB8-98F1-79E3E7128713@zib.de","threadId":"14407","inReplyTo":"alpine.DEB.1.00.0807112226190.8950@racer","subject":"Re: Should we discuss Windows-related changes on git@vger.kernel.org?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-12T08:07:15Z","receivedAt":"2008-07-12T08:07:15Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\n\nOn Jul 11, 2008, at 11:38 PM, Johannes Schindelin wrote:\n\n>> Another example is the discussion about GIT_EXEC_PATH, see\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.msysgit/2633\n>\n> This is a particularly good example that does not matter for Linux,\n> MacOSX, Solaris or the BSDs (Git's principal platforms!) at all.\n>\n> And once this patch hits git@vger, it is still visible to other  \n> platforms.\n\nHmm... on Mac OS X, applications can typically be moved freely in the\nfilesystem.  Installing such an application means no more than mounting\na disk image that contains a directory that you can drag and drop to any\nlocation in the filesystem.  You do not need administrative rights to do\nthis.\n\nFor command line programs, like git, moving the installation freely is\nless common.  Installers often place everything in /usr/local/ (they\nneed administrative rights to do so).  But there are other examples too.\nFor example, I have other vims installed in addition to the system's  \nvim:\n\n   /Applications/vim70/Vim.app\n   /Applications/MacVim-snapshot-24/mvim\n\nthat I can freely move around.\n\nThe result of our discussion on GIT_EXEC_PATH might be useful to achieve\nsomething similar for git -- although I think that it is not an  \nessential\nfeature.\n\n\tSteffen\n"}]}