{"thread":{"id":"8094","subject":"GIT on MinGW problem","startedAt":"2007-05-12T01:13:08Z","lastAt":"2007-05-30T07:06:26Z","messageCount":69,"participants":["Aaron Gray","Junio C Hamano","Han-Wen Nienhuys","Johannes Sixt","Marco Costalba","Johannes Schindelin","Jakub Narebski","Shawn O. Pearce","Steven Grimm","Nix","Marius Storm-Olsen","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41882","messageId":"1dbc01c79432$b4400a80$0200a8c0@AMD2500","threadId":"8094","inReplyTo":null,"subject":"GIT on MinGW problem","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-12T01:13:08Z","receivedAt":"2007-05-12T01:13:08Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":"Hello,\n\nI have installed the git-1.5.1-1.mingw.exe from \nhttp://lilypond.org/git/binaries/mingw/.\n\nOn typing 'git' I get a message box saying :-\n\n The procedure entry point libiconv could not be located in the \ndynamic link library libiconv-2.dll.\n\nI cannot seem to find libiconv-2.dll anywhere either.\n\nHope you can help.\n\nMany thanks in advance,\n\nAaron\n"},{"id":"41883","messageId":"7vveey7scg.fsf@assigned-by-dhcp.cox.net","threadId":"8094","inReplyTo":"1dbc01c79432$b4400a80$0200a8c0@AMD2500","subject":"Re: GIT on MinGW problem","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-12T01:17:51Z","receivedAt":"2007-05-12T01:17:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Aaron Gray\" writes:\n\n> Hello,\n>\n> I have installed the git-1.5.1-1.mingw.exe from\n> http://lilypond.org/git/binaries/mingw/.\n>\n> On typing 'git' I get a message box saying :-\n>\n> The procedure entry point libiconv could not be located in the\n> dynamic link library libiconv-2.dll.\n>\n> I cannot seem to find libiconv-2.dll anywhere either.\n>\n> Hope you can help.\n>\n> Many thanks in advance,\n>\n> Aaron\n\nEven myself (who does not have anything to do with Windows\nmachines) remembers seeing this exact thing in the past 12\nhours:\n\n\tarticle.gmane.org/gmane.comp.version-control.git/46962\n\nPlease check the archive before asking. Thanks.\n"},{"id":"41889","messageId":"1def01c7943c$dfe20a30$0200a8c0@AMD2500","threadId":"8094","inReplyTo":"7vveey7scg.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT on MinGW problem","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-12T02:25:57Z","receivedAt":"2007-05-12T02:25:57Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":">> I cannot seem to find libiconv-2.dll anywhere either.\n>\n> Even myself (who does not have anything to do with Windows\n> machines) remembers seeing this exact thing in the past 12\n> hours:\n>\n> article.gmane.org/gmane.comp.version-control.git/46962\n>\n> Please check the archive before asking. Thanks.\n>\n\nSorry.\n\nThe correct link is :-\n\nhttp://sourceforge.net/project/downloading.php?group_id=23617&use_mirror=kent&filename=diffutils-2.8.7-1-dep.zip&19135304\n\nrenamed libiconv2.dll to libiconv-2.dll\n\nAaron \n"},{"id":"41894","messageId":"464534EE.30904@xs4all.nl","threadId":"8094","inReplyTo":"1dbc01c79432$b4400a80$0200a8c0@AMD2500","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-12T03:30:54Z","receivedAt":"2007-05-12T03:30:54Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Aaron Gray escreveu:\n> Hello,\n> \n> I have installed the git-1.5.1-1.mingw.exe from\n> http://lilypond.org/git/binaries/mingw/.\n> \n> On typing 'git' I get a message box saying :-\n> \n> The procedure entry point libiconv could not be located in the\n> dynamic link library libiconv-2.dll.\n> \n> I cannot seem to find libiconv-2.dll anywhere either.\n\nThis should be fixed in \n\nhttp://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe\n\nit should also set $PATH.\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43221","messageId":"4656A304.AF39A0B6@eudaptics.com","threadId":"8094","inReplyTo":"464534EE.30904@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-25T08:49:08Z","receivedAt":"2007-05-25T08:49:08Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Han-Wen Nienhuys wrote:\n> \n> Aaron Gray escreveu:\n> > Hello,\n> >\n> > I have installed the git-1.5.1-1.mingw.exe from\n> > http://lilypond.org/git/binaries/mingw/.\n> >\n> > On typing 'git' I get a message box saying :-\n> >\n> > The procedure entry point libiconv could not be located in the\n> > dynamic link library libiconv-2.dll.\n> >\n> > I cannot seem to find libiconv-2.dll anywhere either.\n> \n> This should be fixed in\n> \n> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe\n> \n> it should also set $PATH.\n\nI gave this some more testing and it turns out to be a well working\ntoolset. Thank you very much!\n\nThere were still some issues remaining. These are the ones that should\nbe fixable easily:\n\n* git version reports just:\n\n\tgit version -dirty\n\nSince git-gui parses the output of git version, but does not expect it\nto be of this format, and fails with an error message that it cannot\nparse the version.\n\n* git without an correct git subcommand should list 20 or so commands,\nbut it doesn't. The list is just empty.\n\n* I personally think that the files should go into\n\n\t$PROGRAMFILES/Git/{bin,share,lib}\ninstead of\n\t$PROGRAMFILES/Git/usr/{bin,share,lib}\n\nThe more difficult to solve problems are:\n\n* git-gui and gitk don't work out of the box because they have the path\nto wish hardcoded. They can't be started from CMD at all. I have written\nwrappers gitk.cmd and git-gui.cmd with these 2 lines:\n\n@echo off\nstart wish84 D:/MSYS/1.0/git/bin/gitk %*\n\nBut as you can see, the path is still hard-coded (but it is good enough\nfor me for the moment).\n\n* perl scripts like git-remote contain a hard-coded path to the\ninstallation directory and don't work for this reason.\n\n-- Hannes\n"},{"id":"43222","messageId":"e5bfff550705250245l507e9901o669c9aa57c5fccf7@mail.gmail.com","threadId":"8094","inReplyTo":"4656A304.AF39A0B6@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-25T09:45:09Z","receivedAt":"2007-05-25T09:45:09Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/25/07, Johannes Sixt wrote:\n> Han-Wen Nienhuys wrote:\n> >\n> > Aaron Gray escreveu:\n> > > Hello,\n> > >\n> > > I have installed the git-1.5.1-1.mingw.exe from\n> > > http://lilypond.org/git/binaries/mingw/.\n> > >\n> > > On typing 'git' I get a message box saying :-\n> > >\n> > > The procedure entry point libiconv could not be located in the\n> > > dynamic link library libiconv-2.dll.\n> > >\n> > > I cannot seem to find libiconv-2.dll anywhere either.\n> >\n> > This should be fixed in\n> >\n> > http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe\n> >\n> > it should also set $PATH.\n>\n> I gave this some more testing and it turns out to be a well working\n> toolset. Thank you very much!\n>\n> There were still some issues remaining. These are the ones that should\n> be fixable easily:\n>\n> * git version reports just:\n>\n> git version -dirty\n>\n> Since git-gui parses the output of git version, but does not expect it\n> to be of this format, and fails with an error message that it cannot\n> parse the version.\n>\n\nYes, an error message at startup is shown also with qgit.\n\nAlso 'git status' seems to have some issues.\n\n\n Marco\n"},{"id":"43229","messageId":"Pine.LNX.4.64.0705251113280.4648@racer.site","threadId":"8094","inReplyTo":"4656A304.AF39A0B6@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-25T10:20:42Z","receivedAt":"2007-05-25T10:20:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 25 May 2007, Johannes Sixt wrote:\n\n> * I personally think that the files should go into\n> \n> \t$PROGRAMFILES/Git/{bin,share,lib}\n> instead of\n> \t$PROGRAMFILES/Git/usr/{bin,share,lib}\n\nAgree. It is trivial, but it will help others. It might also be a good \nidea to have a shortcut in \"$PF/Git/Git Gui.lnk\" to the git gui (once it \nis working, that is).\n\n> * git-gui and gitk don't work out of the box because they have the path\n> to wish hardcoded. They can't be started from CMD at all. I have written\n> wrappers gitk.cmd and git-gui.cmd with these 2 lines:\n> \n> @echo off\n> start wish84 D:/MSYS/1.0/git/bin/gitk %*\n> \n> But as you can see, the path is still hard-coded (but it is good enough\n> for me for the moment).\n\nI'd also like to see bash, perl and wish bundled with the install (Windows \nlusers are so used to one big install package, so it is an _advantage_ to \nhave a bigger download).\n\n> * perl scripts like git-remote contain a hard-coded path to the\n> installation directory and don't work for this reason.\n\nGITPERLLIB should be set from the wrapper script, I think.\n\nCiao,\nDscho\n"},{"id":"43234","messageId":"4656C363.FF9835E5@eudaptics.com","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705251113280.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-25T11:07:15Z","receivedAt":"2007-05-25T11:07:15Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 25 May 2007, Johannes Sixt wrote:\n> > * perl scripts like git-remote contain a hard-coded path to the\n> > installation directory and don't work for this reason.\n> \n> GITPERLLIB should be set from the wrapper script, I think.\n\nThe clean way is certainly to derive the directory from $0:\n\nuse lib $0 =~ /^(.*)([\\/\\\\]+[^\\/\\\\]*){2}$/ ? (\"$1/lib\") : ();\n\n(although I'm not sure whether this would work during 'make test').\n\n-- Hannes\n"},{"id":"43296","messageId":"075401c79f14$deff63f0$0200a8c0@AMD2500","threadId":"8094","inReplyTo":"4656A304.AF39A0B6@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-25T21:37:18Z","receivedAt":"2007-05-25T21:37:18Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":"> Han-Wen Nienhuys wrote:\n>> \n>> Aaron Gray escreveu:\n>> > Hello,\n>> >\n>> > I have installed the git-1.5.1-1.mingw.exe from\n>> > http://lilypond.org/git/binaries/mingw/.\n>> >\n>> > On typing 'git' I get a message box saying :-\n>> >\n>> > The procedure entry point libiconv could not be located in the\n>> > dynamic link library libiconv-2.dll.\n>> >\n>> > I cannot seem to find libiconv-2.dll anywhere either.\n>> \n>> This should be fixed in\n>> \n>> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe\n>> \n>> it should also set $PATH.\n> \n> I gave this some more testing and it turns out to be a well working\n> toolset. Thank you very much!\n> \n> There were still some issues remaining. These are the ones that should\n> be fixable easily:\n> \n> * git version reports just:\n> \n> git version -dirty\n> \n> Since git-gui parses the output of git version, but does not expect it\n> to be of this format, and fails with an error message that it cannot\n> parse the version.\n> \n> * git without an correct git subcommand should list 20 or so commands,\n> but it doesn't. The list is just empty.\n> \n> * I personally think that the files should go into\n> \n> $PROGRAMFILES/Git/{bin,share,lib}\n> instead of\n> $PROGRAMFILES/Git/usr/{bin,share,lib}\n> \n> The more difficult to solve problems are:\n> \n> * git-gui and gitk don't work out of the box because they have the path\n> to wish hardcoded. They can't be started from CMD at all. I have written\n> wrappers gitk.cmd and git-gui.cmd with these 2 lines:\n> \n> @echo off\n> start wish84 D:/MSYS/1.0/git/bin/gitk %*\n> \n> But as you can see, the path is still hard-coded (but it is good enough\n> for me for the moment).\n> \n> * perl scripts like git-remote contain a hard-coded path to the\n> installation directory and don't work for this reason.\n\nAre git init and git clone working for you ?\n\nAaron\n"},{"id":"43362","messageId":"f3a2ke$9s7$1@sea.gmane.org","threadId":"8094","inReplyTo":"4656A304.AF39A0B6@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-26T19:41:22Z","receivedAt":"2007-05-26T19:41:22Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Sixt escreveu:\n>>\n>> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe\n>>\n>> it should also set $PATH.\n> \n> I gave this some more testing and it turns out to be a well working\n> toolset. Thank you very much!\n> \n> There were still some issues remaining. These are the ones that should\n> be fixable easily:\n> \n> * git version reports just:\n> \n> \tgit version -dirty\n> \n> Since git-gui parses the output of git version, but does not expect it\n> to be of this format, and fails with an error message that it cannot\n> parse the version.\n\nMy biggest problem is that the makefiles of git are an unmitigated\ndisaster, and there seems to be little interest in solving this\nproblem. For example, my suggestion to introduce autoconf was met with\nderision. Most of the effort was patching out makefile parts that\nmade my life harder. I may have patched the version part out as well.\n\nIn this, part of the pain is that Git tries to guess the version number\nby itself in a complicated way. It would be easiest if I could just \nspecify the version number externally. In that case I can sync the installer\nversion number (1.5.1-2 in this case) and the version that git reports.\n\n\n> * git without an correct git subcommand should list 20 or so commands,\n> but it doesn't. The list is just empty.\n\n\nthere was a problem in generate cmd list, (I have sort in /bin/ ). I\nrecommend to add\n\n set -u -v \n\nto all shell scripts so this doesn't go unnoticed.\n\n> * I personally think that the files should go into\n> \n> \t$PROGRAMFILES/Git/{bin,share,lib}\n> instead of\n> \t$PROGRAMFILES/Git/usr/{bin,share,lib}\n> \n> The more difficult to solve problems are:\n\nI understand, but it makes my life a lot more difficult.\n\n> * git-gui and gitk don't work out of the box because they have the path\n> to wish hardcoded. They can't be started from CMD at all. I have written\n> wrappers gitk.cmd and git-gui.cmd with these 2 lines:\n> \n> @echo off\n> start wish84 D:/MSYS/1.0/git/bin/gitk %*\n> \n> But as you can see, the path is still hard-coded (but it is good enough\n> for me for the moment).\n\nThe only solution is to x-compile wish and include it as well. I need several \nstrong drinks to start trying this. Is there a MinGW wish port?\n\n> * perl scripts like git-remote contain a hard-coded path to the\n> installation directory and don't work for this reason.\n\nI actually commented out most perl stuff because the Makefile is just\ntoo spaghetti-ish. I seem to have forgotten commenting out git-remote.\n\nI thought the policy was to abandon Perl scripts for git commands?\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43363","messageId":"46588DA4.5020109@xs4all.nl","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705251113280.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-26T19:42:28Z","receivedAt":"2007-05-26T19:42:28Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin escreveu:\n> Hi,\n> \n> On Fri, 25 May 2007, Johannes Sixt wrote:\n> \n>> * I personally think that the files should go into\n>>\n>> \t$PROGRAMFILES/Git/{bin,share,lib}\n>> instead of\n>> \t$PROGRAMFILES/Git/usr/{bin,share,lib}\n> \n> Agree. It is trivial, but it will help others. It might also be a good \n> idea to have a shortcut in \"$PF/Git/Git Gui.lnk\" to the git gui (once it \n> is working, that is).\n> \n>> * git-gui and gitk don't work out of the box because they have the path\n>> to wish hardcoded. They can't be started from CMD at all. I have written\n>> wrappers gitk.cmd and git-gui.cmd with these 2 lines:\n>>\n>> @echo off\n>> start wish84 D:/MSYS/1.0/git/bin/gitk %*\n>>\n>> But as you can see, the path is still hard-coded (but it is good enough\n>> for me for the moment).\n> \n> I'd also like to see bash, perl and wish bundled with the install (Windows \n\nWhere is the info on the wish and bash port to Mingw?\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43371","messageId":"Pine.LNX.4.64.0705262311380.4648@racer.site","threadId":"8094","inReplyTo":"46588DA4.5020109@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-26T22:17:33Z","receivedAt":"2007-05-26T22:17:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[before answering: a big thank you, Han-Wen, for doing that work. I think \nit is very valuable, especially because except Johannes Sixt, I have yet \nto encounter a person wanting \"naive\" Windows Git, but not hiding under \nthe next rock when it comes to work on it.]\n\nOn Sat, 26 May 2007, Han-Wen Nienhuys wrote:\n\n> Johannes Schindelin escreveu:\n> > \n> > On Fri, 25 May 2007, Johannes Sixt wrote:\n> > \n> >> * I personally think that the files should go into\n> >>\n> >> \t$PROGRAMFILES/Git/{bin,share,lib}\n> >> instead of\n> >> \t$PROGRAMFILES/Git/usr/{bin,share,lib}\n> > \n> > Agree. It is trivial, but it will help others. It might also be a good \n> > idea to have a shortcut in \"$PF/Git/Git Gui.lnk\" to the git gui (once it \n> > is working, that is).\n> > \n> >> * git-gui and gitk don't work out of the box because they have the path\n> >> to wish hardcoded. They can't be started from CMD at all. I have written\n> >> wrappers gitk.cmd and git-gui.cmd with these 2 lines:\n> >>\n> >> @echo off\n> >> start wish84 D:/MSYS/1.0/git/bin/gitk %*\n> >>\n> >> But as you can see, the path is still hard-coded (but it is good enough\n> >> for me for the moment).\n> > \n> > I'd also like to see bash, perl and wish bundled with the install (Windows \n> \n> Where is the info on the wish and bash port to Mingw?\n\nI recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) \nWorked out of the box:\n\n\thttp://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz\n\thttp://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz\n\n(Now, if only Python worked like that...)\n\nThere's a bash src in the Snapshot package of MinGW:\n\n\thttp://prdownloads.sf.net/mingw/bash-2.05b-MSYS-src.tar.bz2?download\n\nCiao,\nDscoh\n"},{"id":"43372","messageId":"Pine.LNX.4.64.0705262318190.4648@racer.site","threadId":"8094","inReplyTo":"f3a2ke$9s7$1@sea.gmane.org","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-26T22:26:48Z","receivedAt":"2007-05-26T22:26:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 26 May 2007, Han-Wen Nienhuys wrote:\n\n> Johannes Sixt escreveu:\n> >>\n> >> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe\n> >>\n> >> it should also set $PATH.\n> > \n> > I gave this some more testing and it turns out to be a well working\n> > toolset. Thank you very much!\n> > \n> > There were still some issues remaining. These are the ones that should\n> > be fixable easily:\n> > \n> > * git version reports just:\n> > \n> > \tgit version -dirty\n> > \n> > Since git-gui parses the output of git version, but does not expect it\n> > to be of this format, and fails with an error message that it cannot\n> > parse the version.\n> \n> My biggest problem is that the makefiles of git are an unmitigated\n> disaster, and there seems to be little interest in solving this\n> problem. For example, my suggestion to introduce autoconf was met with\n> derision.\n\nWell, I would not call it derision. But many people have had bad \nexperience with that big mess which is autoconf, so we were more than \nreluctant to do it.\n\nIn the meantime, we do have a configure.ac, though. In general, you do not \nhave to run it, but you can if \"make\" does not work out of the box.\n\nI have to admit that it is unclear to me what are the problems with the \nMakefile with regards to gub. I think I will just bite the apple, and \ndownload that beast to try it myself.\n\n> In this, part of the pain is that Git tries to guess the version number\n> by itself in a complicated way.\n\nYes, I never understood that myself why it has to be so complicated. But \nthen, it did not make _my_ life hard, so I did not care.\n\n> I thought the policy was to abandon Perl scripts for git commands?\n\nAlas, no. We even have picked up a few since.\n\nOTOH, it _is_ a nice thing to protohype the new commands as shell or perl \nscripts. When they stabilize enough, convert them to builtins.\n\nThere are exactly 4 perl scripts left that I regularly use:\n\nadd--interactive, cvsimport, remote and svn.\n\nI somehow have the feeling that it is not worth the effort to convert \ncvsimport and svn. With add--interactive, I think it's better to leave it \nas is before Junio goes on another \"what have I done? why did I have to \nadd _this_?\" spree.\n\nBut remote will soon be the center of my crosshairs.\n\nCiao,\nDscho\n"},{"id":"43374","messageId":"7v4plzi508.fsf@assigned-by-dhcp.cox.net","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705262318190.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-26T22:39:35Z","receivedAt":"2007-05-26T22:39:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> In this, part of the pain is that Git tries to guess the version number\n>> by itself in a complicated way.\n>\n> Yes, I never understood that myself why it has to be so complicated. But \n> then, it did not make _my_ life hard, so I did not care.\n\n\"echo \"MyVersionNumber\" >version && make\"?\n\n> OTOH, it _is_ a nice thing to protohype the new commands as shell or perl \n> scripts. When they stabilize enough, convert them to builtins.\n\nProtohype is a nice word. Throw out a half-working stuff and\nadvertise it as the best thing since sliced bread even before it\nstarts to being useful ;-)\n\n> There are exactly 4 perl scripts left that I regularly use:\n>\n> add--interactive, cvsimport, remote and svn.\n>\n> I somehow have the feeling that it is not worth the effort to convert \n> cvsimport and svn. With add--interactive, I think it's better to leave it \n> as is before Junio goes on another \"what have I done? why did I have to \n> add _this_?\" spree.\n\nI do not follow you here.\n\n> But remote will soon be the center of my crosshairs.\n\nI am afraid that it might be a bit premature.\n\nI've been hoping that we can make git-clone a thin wrapper\naround init/remote/fetch/checkout. For one thing, we would want\nto split the separate-remotes layout and bareness to create\n\"mirror\" (I called it \"pure\" previously, but this is really a\nmirror) layout for git-clone, among other things, and that kind\nof enhancements would need to be done inside git-remote.\n"},{"id":"43375","messageId":"Pine.LNX.4.64.0705262343390.4648@racer.site","threadId":"8094","inReplyTo":"7v4plzi508.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-26T22:45:41Z","receivedAt":"2007-05-26T22:45:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 26 May 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> In this, part of the pain is that Git tries to guess the version number\n> >> by itself in a complicated way.\n> >\n> > Yes, I never understood that myself why it has to be so complicated. But \n> > then, it did not make _my_ life hard, so I did not care.\n> \n> \"echo \"MyVersionNumber\" >version && make\"?\n\nGood to know!\n\n> > OTOH, it _is_ a nice thing to protohype the new commands as shell or perl \n> > scripts. When they stabilize enough, convert them to builtins.\n> \n> Protohype is a nice word. Throw out a half-working stuff and\n> advertise it as the best thing since sliced bread even before it\n> starts to being useful ;-)\n\nIt started out as a typo. But then I liked it so much that I kept it ;-)\n\n> > With add--interactive, I think it's better to leave it [...]\n> \n> I do not follow you here.\n\nYou mentioned several times that you were unsure if add--interactive was a \ngood idea. But I like it very much.\n\n> \n> > But remote will soon be the center of my crosshairs.\n> \n> I am afraid that it might be a bit premature.\n> \n> I've been hoping that we can make git-clone a thin wrapper\n> around init/remote/fetch/checkout. For one thing, we would want\n> to split the separate-remotes layout and bareness to create\n> \"mirror\" (I called it \"pure\" previously, but this is really a\n> mirror) layout for git-clone, among other things, and that kind\n> of enhancements would need to be done inside git-remote.\n\nFair enough.\n\nCiao,\nDscho\n"},{"id":"43377","messageId":"4658BA64.2050904@xs4all.nl","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705262318190.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-26T22:53:24Z","receivedAt":"2007-05-26T22:53:24Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin escreveu:\n>>> * git version reports just:\n>>>\n>>> \tgit version -dirty\n>>>\n>>> Since git-gui parses the output of git version, but does not expect it\n>>> to be of this format, and fails with an error message that it cannot\n>>> parse the version.\n>> My biggest problem is that the makefiles of git are an unmitigated\n>> disaster, and there seems to be little interest in solving this\n>> problem. For example, my suggestion to introduce autoconf was met with\n>> derision.\n> \n> Well, I would not call it derision. But many people have had bad \n> experience with that big mess which is autoconf, so we were more than \n> reluctant to do it.\n\nautoconf is not that big a mess, but it is a macrolanguage, which does\ncome with its pitfalls. Automake and libtool are the messy things,\nand I prefer to stay away from them as far as possible.\n\nThe point of autoconf is to generate a hyper-portable script that\ndeals with all the different flavors of shell breakage. For the user\nit simplifies compiling packages enormously, which IMO should be the\nguiding concern if you like to have users.\n\nFor a pretty run-of-the-mill tool like git (dependency wise), it\nshould be easy to write a working configure.in.\n\nMy favorite approach is: use autoconf to generate\n\n - config.h\n \n - config.make\n\nAll settings that force recompile should be in config.h, and standard\nC methods to track dependencies will take care of the recompilation\nwhen anything changes. The main Makefile includes config.make, and\ncontains all configurable settings. The Makefile only needs to be\nedited by developers. Require GNU Make so you can write sane\nmakefiles.\n\nInstead, we have a Makefile that relies on an esoteric combination of\nperl and shell scripting inside Makefiles.\n\nAlso, the Makefile says.\n\n # Shell quote (do not use $(call) to accommodate ancient setups);\n\nI think it would be better to have a clearly defined list of optional\nand required dependencies with version numbers, and then stand by\nthat. For example, Make uses a completely autoconf/libtool based\ncompile process, and is easy to compile. I think it would be\nreasonable to require a recent make, say 3.80, and then use its\nfeatures. \n\n> In the meantime, we do have a configure.ac, though. In general, you do not \n> have to run it, but you can if \"make\" does not work out of the box.\n> \n> I have to admit that it is unclear to me what are the problems with the \n> Makefile with regards to gub. I think I will just bite the apple, and \n> download that beast to try it myself.\n\n>From what I recall, it tries to be too clever in detecting changes \nof the make command line, forcing a recompile (possibly with erroneous paths)\nduring the \n\n make install\n\nI might be mistaken, though. I tried to get something up as fast as\npossible.\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43385","messageId":"f3agkk$bhn$1@sea.gmane.org","threadId":"8094","inReplyTo":"4658BA64.2050904@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-26T23:47:19Z","receivedAt":"2007-05-26T23:47:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Han-Wen Nienhuys wrote:\n\n> Johannes Schindelin escreveu:\n\n>>>> * git version reports just:\n>>>>\n>>>> git version -dirty\n>>>>\n>>>> Since git-gui parses the output of git version, but does not expect it\n>>>> to be of this format, and fails with an error message that it cannot\n>>>> parse the version.\n>>> My biggest problem is that the makefiles of git are an unmitigated\n>>> disaster, and there seems to be little interest in solving this\n>>> problem. For example, my suggestion to introduce autoconf was met with\n>>> derision.\n>> \n>> Well, I would not call it derision. But many people have had bad \n>> experience with that big mess which is autoconf, so we were more than \n>> reluctant to do it.\n> \n> autoconf is not that big a mess, but it is a macrolanguage, which does\n> come with its pitfalls. Automake and libtool are the messy things,\n> and I prefer to stay away from them as far as possible.\n> \n> The point of autoconf is to generate a hyper-portable script that\n> deals with all the different flavors of shell breakage. For the user\n> it simplifies compiling packages enormously, which IMO should be the\n> guiding concern if you like to have users.\n> \n> For a pretty run-of-the-mill tool like git (dependency wise), it\n> should be easy to write a working configure.in.\n> \n> My favorite approach is: use autoconf to generate\n> \n> - config.h\n> \n> - config.make\n> \n> All settings that force recompile should be in config.h, and standard\n> C methods to track dependencies will take care of the recompilation\n> when anything changes. The main Makefile includes config.make, and\n> contains all configurable settings. The Makefile only needs to be\n> edited by developers. Require GNU Make so you can write sane\n> makefiles.\n\nActually we do have configure.ac script; ./configure (result of\n\"make configure\") is not distributed in the tarball I think.\nIt generates file named not config.make, but config.mak.autogen.\nBy the way, the .autogen suffix is to distinguish ./configure generated file\nfrom handmade user configureation, but I have no idea why it is config.mak\nnot config.make. But there is no config.h -- we do not rely on automake and\nautoheader.\n\nIf you are well wersed in autoconf, feel free to improve our configure.ac\nscript.\n \n> Instead, we have a Makefile that relies on an esoteric combination of\n> perl and shell scripting inside Makefiles.\n\nThe idea is to be able to get reasonable defaults (depending on system of\ncourse) without needing autoconf, and running quite long on some\nplatform ./configure script detection...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"43395","messageId":"4659259D.4000803@xs4all.nl","threadId":"8094","inReplyTo":"f3agkk$bhn$1@sea.gmane.org","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T06:30:53Z","receivedAt":"2007-05-27T06:30:53Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Jakub Narebski escreveu:\n\n>> Instead, we have a Makefile that relies on an esoteric combination of\n>> perl and shell scripting inside Makefiles.\n> \n> The idea is to be able to get reasonable defaults (depending on system of\n\nThis saves the user on Linux or similar platform one ./configure call. For\nthe rest it means editing makefiles. I'm not sure if that is an improvement\nover the standard \n\n configure ; make ; make install\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43396","messageId":"20070527063902.GB28023@spearce.org","threadId":"8094","inReplyTo":"4659259D.4000803@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-27T06:39:02Z","receivedAt":"2007-05-27T06:39:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Han-Wen Nienhuys wrote:\n> Jakub Narebski escreveu:\n> \n> >> Instead, we have a Makefile that relies on an esoteric combination of\n> >> perl and shell scripting inside Makefiles.\n> > \n> > The idea is to be able to get reasonable defaults (depending on system of\n> \n> This saves the user on Linux or similar platform one ./configure call. For\n> the rest it means editing makefiles. I'm not sure if that is an improvement\n> over the standard \n> \n> configure ; make ; make install\n\n[side note: can you please not send both To the list and CC the\nlist on the same message? Pick one, we're all getting two copies\nof messages from you.]\n\nOn systems like Cygwin the fork+exec overheads are very high;\nrunning a \"simple\" configure script can take longer than it\ntakes me to compile Git from scratch. Editing config.mak is\nquite easy; so is passing your choices on the command line to\n`make install`.\n\nPersonally I find:\n\n\tmake NO_CURL=1 install\n\neasier than:\n\n\t./configure --without-curl && make install\n\n-- \nShawn.\n"},{"id":"43397","messageId":"46592B92.9060403@xs4all.nl","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705262311380.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T06:56:18Z","receivedAt":"2007-05-27T06:56:18Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin escreveu:\n\n> I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) \n> Worked out of the box:\n> \n> \thttp://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz\n> \thttp://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz\n> \n\nGCC barfs on:\n\n ((Tcl_Obj **) objv) += (async + 3);\n\n\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43398","messageId":"46592CFE.40303@xs4all.nl","threadId":"8094","inReplyTo":"20070527063902.GB28023@spearce.org","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T07:02:22Z","receivedAt":"2007-05-27T07:02:22Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Shawn O. Pearce escreveu:\n> \n> On systems like Cygwin the fork+exec overheads are very high;\n> running a \"simple\" configure script can take longer than it\n> takes me to compile Git from scratch. Editing config.mak is\n> quite easy; so is passing your choices on the command line to\n> `make install`.\n> \n> Personally I find:\n> \n> \tmake NO_CURL=1 install\n> \n> easier than:\n> \n> \t./configure --without-curl && make install\n\nNO_CURL is a nonstandard option. Every package does it\ndifferently, so this requires users to delve through either\nINSTALL or Makefile. \n\nA well written configure script is able to detect presence\nof a linkable libcurl. \n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43399","messageId":"4659318B.20801@midwinter.com","threadId":"8094","inReplyTo":"46592CFE.40303@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-05-27T07:21:47Z","receivedAt":"2007-05-27T07:21:47Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Han-Wen Nienhuys wrote:\n>> On systems like Cygwin the fork+exec overheads are very high\n> A well written configure script is able to detect presence\n> of a linkable libcurl. \n> \n\nIMO the reasons configure is so unwieldy, at least as it's set up in \nmost open source projects, are that a) it spends 95% of its time \nchecking for things that basically never vary (yes, I have stdlib.h, \nthank you) and that b) it doesn't remember the results from previous \nruns on the same host (I'm just changing the install path; my ints won't \nhave stopped being 32 bits as a result.) I wonder if we could satisfy \nmost people with a configure script -- maybe not based on autoconf -- \nthat is limited in scope to just the things that are currently tweakable \nin the git Makefile.\n\nIf configure ran only, say, 10-15 tests, I bet the fork+exec overhead on \nCygwin would be perfectly tolerable.\n\n-Steve\n"},{"id":"43470","messageId":"200705271109.11942.jnareb@gmail.com","threadId":"8094","inReplyTo":"4659318B.20801@midwinter.com","subject":"Re: GIT on MinGW problem","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-27T09:09:11Z","receivedAt":"2007-05-27T09:09:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 27 May 2007, Steven Grimm wrote:\n> Han-Wen Nienhuys wrote:\n>> Shawn O. Pearce escreveu:\n>>>\n>>> On systems like Cygwin the fork+exec overheads are very high\n>>\n>> A well written configure script is able to detect presence\n>> of a linkable libcurl.\n> \n> IMO the reasons configure is so unwieldy, at least as it's set up in \n> most open source projects, are that a) it spends 95% of its time \n> checking for things that basically never vary (yes, I have stdlib.h, \n> thank you) and that b) it doesn't remember the results from previous \n> runs on the same host (I'm just changing the install path; my ints won't \n> have stopped being 32 bits as a result.)\n\n./configure _can_ cache tests results:\n\n$ ./configure --help\n[...]\n --cache-file=FILE cache test results in FILE [disabled]\n -C, --config-cache alias for `--cache-file=config.cache'\n\nbut it does not do this, and does not check chache by default. Of course\ntests have to be written to make use of cache, IIRC...\n\n> I wonder if we could satisfy \n> most people with a configure script -- maybe not based on autoconf -- \n> that is limited in scope to just the things that are currently tweakable \n> in the git Makefile.\n\nThe problem with handcrafted configure script lies in the portability\nof it. There was an attempt to add such script, IIRC based on mplayer's\nconfigure.sh script, but it turned out it was not portable enough.\nThe conclusion was that sice so many manhours were put into making\nautoconf generate ultra-portable ./configure shell script, it would\nbe better to use it.\n\n> If configure ran only, say, 10-15 tests, I bet the fork+exec overhead on \n> Cygwin would be perfectly tolerable.\n\nThat's not only fork+exec, that is also the fact that large number\nof tests relies on compiling snippets of code...\n\n\nP.S. What do you think about separating the guessing appropriate\nvalues of build variables based on uname to separate file\nconfig.mak.guess, included in Makefile?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"43403","messageId":"Pine.LNX.4.64.0705271143310.4648@racer.site","threadId":"8094","inReplyTo":"4659259D.4000803@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-27T10:46:00Z","receivedAt":"2007-05-27T10:46:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 May 2007, Han-Wen Nienhuys wrote:\n\n> Jakub Narebski escreveu:\n> \n> >> Instead, we have a Makefile that relies on an esoteric combination of \n> >> perl and shell scripting inside Makefiles.\n> > \n> > The idea is to be able to get reasonable defaults (depending on system \n> > of\n> \n> This saves the user on Linux or similar platform one ./configure call. \n\nIt works on Linux, Cygwin, MinGW, last time I checked MacOSX, IRIX, and I \nimagine Solaris, AIX and even other platforms, out of the box.\n\n> For the rest it means editing makefiles. I'm not sure if that is an \n> improvement over the standard\n> \n> configure ; make ; make install\n\nATM you have to do autoconf before that. But that should work, really.\n\nCiao,\nDscho\n"},{"id":"43405","messageId":"Pine.LNX.4.64.0705271149450.4648@racer.site","threadId":"8094","inReplyTo":"46592B92.9060403@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-27T10:52:23Z","receivedAt":"2007-05-27T10:52:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 May 2007, Han-Wen Nienhuys wrote:\n\n> Johannes Schindelin escreveu:\n> \n> > I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) \n> > Worked out of the box:\n> > \n> > \thttp://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz\n> > \thttp://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz\n> > \n> \n> GCC barfs on:\n> \n> ((Tcl_Obj **) objv) += (async + 3);\n\nAh yes, I was using MinGW's own GCC, which is GCC 3.something.\n\nIt is a new \"feature\" of GCC 4.x to disallow constructs like these. \n(Probably because GCC people think that other people are not intelligent \nenough to understand such constructs, and therefore prohibit their use.)\n\nCiao,\nDscho\n"},{"id":"43442","messageId":"4659BA07.4080307@xs4all.nl","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705271149450.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T17:04:07Z","receivedAt":"2007-05-27T17:04:07Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin escreveu:\n\n>> ((Tcl_Obj **) objv) += (async + 3);\n> \n> Ah yes, I was using MinGW's own GCC, which is GCC 3.something.\n> \n> It is a new \"feature\" of GCC 4.x to disallow constructs like these. \n> (Probably because GCC people think that other people are not intelligent \n> enough to understand such constructs, and therefore prohibit their use.)\n\nI very much doubt that. GCC uses type information to determine whether \npointers might be aliased. I think disallowing such constructs helps with\ncompiler optimization.\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43446","messageId":"4659D306.6030803@xs4all.nl","threadId":"8094","inReplyTo":"f3a2ke$9s7$1@sea.gmane.org","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T18:50:46Z","receivedAt":"2007-05-27T18:50:46Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Han-Wen Nienhuys escreveu:\n> The only solution is to x-compile wish and include it as well. I need several \n> strong drinks to start trying this. Is there a MinGW wish port?\n\nIt turns out that spending a night in a brazilian/japanese karaoke bar\nwhere thumping disco beats of the sadly deserted dance area permeates\nthe bleary out-of-tune portuguese singing of hormonally driven women did\nenough to melt my mind.\n\nThere is a 1.5.2-3 installer which includes a cross-compiled tcltk. \n\n http://lilypond.org/git/binaries/mingw/\n\nWhat is the proper way to have the 'gitk' command start up with wish\nautomatically?\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43448","messageId":"f3cnm6$gda$1@sea.gmane.org","threadId":"8094","inReplyTo":"4659D306.6030803@xs4all.nl","subject":"GIT on MinGW, with tcltk for gitk","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T19:52:47Z","receivedAt":"2007-05-27T19:52:47Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Han-Wen Nienhuys escreveu:\n> There is a 1.5.2-3 installer which includes a cross-compiled tcltk. \n> \n> http://lilypond.org/git/binaries/mingw/\n> \n> What is the proper way to have the 'gitk' command start up with wish\n> automatically?\n\nI've just uploaded 1.5.2-5, which also writes a gitk.bat file, containing\nproper paths. However, I can't get it working in Wine. Any windows user\nthat cares to test? \n\n http://lilypond.org/git/binaries/mingw/git-1.5.2-5.mingw.exe\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43452","messageId":"00a601c7a09f$218c1020$0200a8c0@AMD2500","threadId":"8094","inReplyTo":"f3cnm6$gda$1@sea.gmane.org","subject":"Re: GIT on MinGW, with tcltk for gitk","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-27T20:39:32Z","receivedAt":"2007-05-27T20:39:32Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":"> Han-Wen Nienhuys escreveu:\n>> There is a 1.5.2-3 installer which includes a cross-compiled tcltk. \n>> \n>> http://lilypond.org/git/binaries/mingw/\n>> \n>> What is the proper way to have the 'gitk' command start up with wish\n>> automatically?\n> \n> I've just uploaded 1.5.2-5, which also writes a gitk.bat file, containing\n> proper paths. However, I can't get it working in Wine. Any windows user\n> that cares to test? \n> \n> http://lilypond.org/git/binaries/mingw/git-1.5.2-5.mingw.exe\n> \n\ngit clone or git-clone are not accessable still.\n\nC:\\Work\\test>git init\nwarning: templates not found C:/Program Files/Git/usr/bin@template_dir@\nInitialized empty Git repository in .git/\n\nAaron\n"},{"id":"43454","messageId":"4659EDBC.7080804@xs4all.nl","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705262311380.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T20:44:44Z","receivedAt":"2007-05-27T20:44:44Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin escreveu:\n> There's a bash src in the Snapshot package of MinGW:\n> \n> \thttp://prdownloads.sf.net/mingw/bash-2.05b-MSYS-src.tar.bz2?download\n\nthis thoroughly confuses me. \n\nDoes it require MSYS? If yes, where can I find the MSYS source code?\n\nWhat does it mean that: \n\nHowever, it is important to remember that NO executables other than\nwhat ships with MSYS should be placed in the MSYS \" bin\"\nsubdirectory. Therefore, do not attempt to \"merge\" the two packages.\n(http://www.mingw.org/mingwfaq.shtml#faq-msys)\n\nIf this is true, this will mess up my installers.\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43455","messageId":"4659F5D0.2070406@xs4all.nl","threadId":"8094","inReplyTo":"00a601c7a09f$218c1020$0200a8c0@AMD2500","subject":"Re: GIT on MinGW, with tcltk for gitk","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T21:19:12Z","receivedAt":"2007-05-27T21:19:12Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Aaron Gray escreveu:\n\n> C:\\Work\\test>git init\n> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@\n> Initialized empty Git repository in .git/\n> \n> Aaron\n\nThanks for the report. Can you try again with 1.5.2-7 ? It should be available\nin a few minutes.\n\nAlso, can you tell me if gitk.bat works for you?\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43456","messageId":"00b901c7a0a5$77983420$0200a8c0@AMD2500","threadId":"8094","inReplyTo":"4659F5D0.2070406@xs4all.nl","subject":"Re: GIT on MinGW, with tcltk for gitk","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-27T21:24:49Z","receivedAt":"2007-05-27T21:24:49Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":"> Aaron Gray escreveu:\n>\n>> C:\\Work\\test>git init\n>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@\n>> Initialized empty Git repository in .git/\n>>\n>> Aaron\n>\n> Thanks for the report. Can you try again with 1.5.2-7 ? It should be \n> available\n> in a few minutes.\n\nOkay, I'm up for all the testing thats needed. Just dont know the territory \nthat well though, as I am a Windozer :)\n\n> Also, can you tell me if gitk.bat works for you?\n\nOkay, I just type 'gitk' ?\n\nAnd what happens ?\n\nThanks,\n\nAaron\n"},{"id":"43457","messageId":"Pine.LNX.4.64.0705272222200.4648@racer.site","threadId":"8094","inReplyTo":"f329bf540705271417k1874c1f2u3acc98dc25e058b9@mail.gmail.com","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-27T21:26:07Z","receivedAt":"2007-05-27T21:26:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 May 2007, Han-Wen Nienhuys wrote:\n\n> there is a\n> \n> bin/msys-1.0.dll\n> bin/libW11.dll\n> \n> inside the tarball. I want to know what they are, and how to build them.\n\nOops. I missed that. I guess that msys-1.0.dll is built from\n\n\thttp://downloads.sourceforge.net/mingw/msys-1.0.10-src.tar.bz2\n\nand that libW11.dll is built from some package in\n\n\thttp://sourceforge.net/project/showfiles.php?group_id=37352\n\nCiao,\nDscho\n"},{"id":"43459","messageId":"00c401c7a0a7$8a5690a0$0200a8c0@AMD2500","threadId":"8094","inReplyTo":"00b901c7a0a5$77983420$0200a8c0@AMD2500","subject":"Re: GIT on MinGW, with tcltk for gitk","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-27T21:39:39Z","receivedAt":"2007-05-27T21:39:39Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":">> Aaron Gray escreveu:\n>>\n>>> C:\\Work\\test>git init\n>>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@\n>>> Initialized empty Git repository in .git/\n>>>\n>>> Aaron\n>>\n>> Thanks for the report. Can you try again with 1.5.2-7 ? It should be \n>> available\n>> in a few minutes.\n>\n> Okay, I'm up for all the testing thats needed. Just dont know the \n> territory that well though, as I am a Windozer :)\n\ngit init appears to work fine now, the template path is found.\n\ngit clone or git-clone is still not working.\n\n'git clone' just gives a list of git's commands.\n\ngit-clone gives usual :-\n\nC:\\Work\\test2>git-clone git://git.kernel.org/pub/scm/git/git.git\n'git-clone' is not recognized as an internal or external command,\noperable program or batch file.\n\n>> Also, can you tell me if gitk.bat works for you?\n>\n> Okay, I just type 'gitk' ?\n\nC:\\Work>gitk\n'\"C:\\Program Files\\Git\\usr\\bin\\wish.exe\"' is not recognized as an internal \nor external command, operable program or batch file.\n\nTheres a file called 'wish84.exe' under 'C:\\Program Files\\Git\\usr\\bin', but \nno wish.exe.\n\nAaron\n\nAaron\n"},{"id":"43461","messageId":"f329bf540705271455m4c0f5a55v14b9a8cc6bd7778d@mail.gmail.com","threadId":"8094","inReplyTo":"00c401c7a0a7$8a5690a0$0200a8c0@AMD2500","subject":"Re: GIT on MinGW, with tcltk for gitk","fromName":"Han-Wen Nienhuys","fromEmail":"hanwenn@gmail.com","sentAt":"2007-05-27T21:55:20Z","receivedAt":"2007-05-27T21:55:20Z","isPatch":false,"sender":{"key":"hanwenn@gmail.com","avatar":"https://gravatar.com/avatar/058832acb8d613baeb6ce9d21b009d9772424a309b9a521330423daef909a27a?d=mp&s=160"},"body":"2007/5/27, Aaron Gray :\n\n> '\"C:\\Program Files\\Git\\usr\\bin\\wish.exe\"' is not recognized as an internal\n> or external command, operable program or batch file.\n>\n> Theres a file called 'wish84.exe' under 'C:\\Program Files\\Git\\usr\\bin', but\n> no wish.exe.\n\ncan you edit this .bat to say wish84.exe iso. wish.exe ?\n\nthnks,\n\n-- \nHan-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43462","messageId":"00ef01c7a0ad$78508e00$0200a8c0@AMD2500","threadId":"8094","inReplyTo":"f329bf540705271455m4c0f5a55v14b9a8cc6bd7778d@mail.gmail.com","subject":"Re: GIT on MinGW, with tcltk for gitk","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-27T22:22:08Z","receivedAt":"2007-05-27T22:22:08Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":"> 2007/5/27, Aaron Gray :\n>\n>> '\"C:\\Program Files\\Git\\usr\\bin\\wish.exe\"' is not recognized as an \n>> internal\n>> or external command, operable program or batch file.\n>>\n>> Theres a file called 'wish84.exe' under 'C:\\Program Files\\Git\\usr\\bin', \n>> but\n>> no wish.exe.\n>\n> can you edit this .bat to say wish84.exe iso. wish.exe ?\n\nGetting message box saying :-\n\n child process exited abnormally\n while executing\n \"close $refd\"\n (proceedure \"readrefs\" line 47)\n invoked from within\n \"readrefs\"\n (file \"C:\\Program Files\\Git\\usr\\bin\\gitk line 6369)\n\n:(\n\nAaron\n"},{"id":"43463","messageId":"465A0490.3050303@xs4all.nl","threadId":"8094","inReplyTo":"00c401c7a0a7$8a5690a0$0200a8c0@AMD2500","subject":"Re: GIT on MinGW, with tcltk for gitk","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T22:22:08Z","receivedAt":"2007-05-27T22:22:08Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Aaron Gray escreveu:\n>>> Aaron Gray escreveu:\n>>>\n>>>> C:\\Work\\test>git init\n>>>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@\n>>>> Initialized empty Git repository in .git/\n>>>>\n>>>> Aaron\n>>>\n>>> Thanks for the report. Can you try again with 1.5.2-7 ? It should be\n>>> available\n>>> in a few minutes.\n>>\n>> Okay, I'm up for all the testing thats needed. Just dont know the\n>> territory that well though, as I am a Windozer :)\n> \n> git init appears to work fine now, the template path is found.\n> \n> git clone or git-clone is still not working.\n> \n\nclone is a shell script. None of the shell scripts work; you'll have\nto install msys bash yourself for now.\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43464","messageId":"465A061C.7010803@xs4all.nl","threadId":"8094","inReplyTo":"00ef01c7a0ad$78508e00$0200a8c0@AMD2500","subject":"Re: GIT on MinGW, with tcltk for gitk","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T22:28:44Z","receivedAt":"2007-05-27T22:28:44Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Aaron Gray escreveu:\n>>>\n>>> Theres a file called 'wish84.exe' under 'C:\\Program\n>>> Files\\Git\\usr\\bin', but\n>>> no wish.exe.\n>>\n>> can you edit this .bat to say wish84.exe iso. wish.exe ?\n> \n> Getting message box saying :-\n> \n> child process exited abnormally\n> while executing\n> \"close $refd\"\n> (proceedure \"readrefs\" line 47)\n> invoked from within\n> \"readrefs\"\n> (file \"C:\\Program Files\\Git\\usr\\bin\\gitk line 6369)\n> \n> :(\n\nIt seems that tcltk was executed; Unfortunately, it does work\nflawlessly under wine, so there is little I can do. I invite windows\nexperts to have a closer look.\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43465","messageId":"012d01c7a0b2$374eea50$0200a8c0@AMD2500","threadId":"8094","inReplyTo":"465A061C.7010803@xs4all.nl","subject":"Re: GIT on MinGW - No symbolic links support","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-27T22:56:08Z","receivedAt":"2007-05-27T22:56:08Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":"Bit of a dampener on GIT on MinGW :-\n\n $ git clone git://git.kernel.org/pub/scm/git/git.git\n Initialized empty Git repository in C:/MSYS/src/git/.git/\n error: git-checkout-index: unable to create symlink RelNotes \n(Function not implemented)\n\nNo Symbolic links !\n\nThere are symbolic links provided by Windows by SFU (Services For Unix) \napparently.\n\nAaron\n\n \n"},{"id":"43471","messageId":"465A11AB.6060906@xs4all.nl","threadId":"8094","inReplyTo":"200705271109.11942.jnareb@gmail.com","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-27T23:18:03Z","receivedAt":"2007-05-27T23:18:03Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Jakub Narebski escreveu:\n> On Sun, 27 May 2007, Steven Grimm wrote:\n>> Han-Wen Nienhuys wrote:\n>>> Shawn O. Pearce escreveu:\n>>>> On systems like Cygwin the fork+exec overheads are very high\n>>> A well written configure script is able to detect presence\n>>> of a linkable libcurl.\n>> IMO the reasons configure is so unwieldy, at least as it's set up in \n>> most open source projects, are that a) it spends 95% of its time \n>> checking for things that basically never vary (yes, I have stdlib.h, \n>> thank you) and that b) it doesn't remember the results from previous \n>> runs on the same host (I'm just changing the install path; my ints won't \n>> have stopped being 32 bits as a result.)\n> \n> ./configure _can_ cache tests results:\n> \n> $ ./configure --help\n> [...]\n> --cache-file=FILE cache test results in FILE [disabled]\n> -C, --config-cache alias for `--cache-file=config.cache'\n> \n> but it does not do this, and does not check chache by default. Of course\n> tests have to be written to make use of cache, IIRC...\n\nSlowness is a misguided argument as well. Yes, configure is slow, but you\nonly have to run it if configure.in , config.h.in or config.make.in chagnes.\nAnd that doesn't happen very often during development.\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43474","messageId":"Pine.LNX.4.64.0705280054140.4648@racer.site","threadId":"8094","inReplyTo":"012d01c7a0b2$374eea50$0200a8c0@AMD2500","subject":"Re: GIT on MinGW - No symbolic links support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-27T23:56:01Z","receivedAt":"2007-05-27T23:56:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 May 2007, Aaron Gray wrote:\n\n> Bit of a dampener on GIT on MinGW :-\n> \n> $ git clone git://git.kernel.org/pub/scm/git/git.git\n> Initialized empty Git repository in C:/MSYS/src/git/.git/\n> error: git-checkout-index: unable to create symlink RelNotes (Function\n> not implemented)\n> \n> No Symbolic links !\n> \n> There are symbolic links provided by Windows by SFU (Services For Unix)\n> apparently.\n\nDoes not work on FAT. Has lots of problems.\n\nThat's why Johannes Sixt pushed for core.symlinks, and got it. So maybe \nthe templates should set core.symlinks=false?\n\nCiao,\nDscho\n"},{"id":"43475","messageId":"Pine.LNX.4.64.0705280059520.4648@racer.site","threadId":"8094","inReplyTo":"465A11AB.6060906@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-28T00:04:09Z","receivedAt":"2007-05-28T00:04:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 May 2007, Han-Wen Nienhuys wrote:\n\n> Jakub Narebski escreveu:\n> > On Sun, 27 May 2007, Steven Grimm wrote:\n> >> Han-Wen Nienhuys wrote:\n> >>> Shawn O. Pearce escreveu:\n> >>>> On systems like Cygwin the fork+exec overheads are very high\n> >>> A well written configure script is able to detect presence\n> >>> of a linkable libcurl.\n> >> IMO the reasons configure is so unwieldy, at least as it's set up in \n> >> most open source projects, are that a) it spends 95% of its time \n> >> checking for things that basically never vary (yes, I have stdlib.h, \n> >> thank you) and that b) it doesn't remember the results from previous \n> >> runs on the same host (I'm just changing the install path; my ints won't \n> >> have stopped being 32 bits as a result.)\n> > \n> > ./configure _can_ cache tests results:\n> > \n> > $ ./configure --help\n> > [...]\n> > --cache-file=FILE cache test results in FILE [disabled]\n> > -C, --config-cache alias for `--cache-file=config.cache'\n> > \n> > but it does not do this, and does not check chache by default. Of course\n> > tests have to be written to make use of cache, IIRC...\n> \n> Slowness is a misguided argument as well. Yes, configure is slow, but \n> you only have to run it if configure.in , config.h.in or config.make.in \n> chagnes. And that doesn't happen very often during development.\n\nSlowness is a good argument. The config does change from time to time (you \nshould know, IICC LilyPond had 36 changes in configure.in through 2006). \nAnd it is annoying.\n\nEspecially when you are trying to debug ./configure.\n\nCiao,\nDscho\n"},{"id":"43477","messageId":"465A22DA.4010504@xs4all.nl","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705280059520.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-28T00:31:22Z","receivedAt":"2007-05-28T00:31:22Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin escreveu:\n>>> but it does not do this, and does not check chache by default. Of course\n>>> tests have to be written to make use of cache, IIRC...\n>> Slowness is a misguided argument as well. Yes, configure is slow, but \n>> you only have to run it if configure.in , config.h.in or config.make.in \n>> chagnes. And that doesn't happen very often during development.\n> \n> Slowness is a good argument. The config does change from time to time (you \n> should know, IICC LilyPond had 36 changes in configure.in through 2006). \n\nCompared to the 100 recompiles during a typical debug/compile day, that's \nnot very significant, IMO.\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43503","messageId":"87646c28jv.fsf@hades.wkstn.nix","threadId":"8094","inReplyTo":"4659BA07.4080307@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2007-05-28T16:54:12Z","receivedAt":"2007-05-28T16:54:12Z","isPatch":false,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 27 May 2007, Han-Wen Nienhuys said:\n\n> Johannes Schindelin escreveu:\n>\n>>> ((Tcl_Obj **) objv) += (async + 3);\n>> \n>> Ah yes, I was using MinGW's own GCC, which is GCC 3.something.\n>> \n>> It is a new \"feature\" of GCC 4.x to disallow constructs like these. \n>> (Probably because GCC people think that other people are not intelligent \n>> enough to understand such constructs, and therefore prohibit their use.)\n>\n> I very much doubt that. GCC uses type information to determine whether \n> pointers might be aliased. I think disallowing such constructs helps with\n> compiler optimization.\n\nActually it was simply too difficult to maintain this extension over the\nC and C++ parser rewrites in the early 4.x timeline. (Also, IIRC, it had\nsome *nasty* ambiguities, especially in C++.)\n\n-- \n`On a scale of one to ten of usefulness, BBC BASIC was several points ahead\n of the competition, scoring a relatively respectable zero.' --- Peter Corlett\n"},{"id":"43545","messageId":"465BD205.5D7BDF5D@eudaptics.com","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705280054140.4648@racer.site","subject":"Re: GIT on MinGW - No symbolic links support","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-29T07:11:01Z","receivedAt":"2007-05-29T07:11:01Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin wrote:\n> \n> Hi,\n> \n> On Sun, 27 May 2007, Aaron Gray wrote:\n> \n> > Bit of a dampener on GIT on MinGW :-\n> >\n> > $ git clone git://git.kernel.org/pub/scm/git/git.git\n> > Initialized empty Git repository in C:/MSYS/src/git/.git/\n> > error: git-checkout-index: unable to create symlink RelNotes (Function\n> > not implemented)\n> >\n> > No Symbolic links !\n> >\n> > There are symbolic links provided by Windows by SFU (Services For Unix)\n> > apparently.\n> \n> Does not work on FAT. Has lots of problems.\n> \n> That's why Johannes Sixt pushed for core.symlinks, and got it. So maybe\n> the templates should set core.symlinks=false?\n\nThis setting should be placed into $(sysconfigdir)/gitconfig. I'll hack\nup something in the next days. The \"challenge\" is that $(sysconfigdir)\nmust not be hardcoded (because the installation location is not known\nuntil runtime). A similar thing I have already done with\n$(template_dir).\n\n-- Hannes\n"},{"id":"43555","messageId":"465C064F.B9CE9379@eudaptics.com","threadId":"8094","inReplyTo":"f3a2ke$9s7$1@sea.gmane.org","subject":"Re: GIT on MinGW problem","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-29T10:54:07Z","receivedAt":"2007-05-29T10:54:07Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Han-Wen Nienhuys wrote:\n> Johannes Sixt escreveu:\n> > * git without an correct git subcommand should list 20 or so commands,\n> > but it doesn't. The list is just empty.\n> \n> there was a problem in generate cmd list, (I have sort in /bin/ ). I\n> recommend to add\n\nStrange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the same\nas /bin/sort.\n\n(For the curious ones: The MinGW port has to replace occurrences of\n'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be picked up\nin shell scripts, because the latter usually comes first in\n%PATH%^W$PATH. Same for 'find'.)\n\n-- Hannes\n"},{"id":"43560","messageId":"465C1252.9020801@trolltech.com","threadId":"8094","inReplyTo":"465C064F.B9CE9379@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-05-29T11:45:22Z","receivedAt":"2007-05-29T11:45:22Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Sixt said the following on 29.05.2007 12:54:\n> Han-Wen Nienhuys wrote:\n>> Johannes Sixt escreveu:\n>>> * git without an correct git subcommand should list 20 or so\n>>> commands, but it doesn't. The list is just empty.\n>> there was a problem in generate cmd list, (I have sort in /bin/\n>> ). I recommend to add\n> \n> Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the\n> same as /bin/sort.\n> \n> (For the curious ones: The MinGW port has to replace occurrences of\n> 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be\n> picked up in shell scripts, because the latter usually comes first\n> in %PATH%^W$PATH. Same for 'find'.)\n\nI get that here too, no matter what I set the mount point to be, and \nwithout the fstab file at all.\n\nAlso, the /bin/gitk.bat file should rather be\n @\"%~d0%~p0wish84.exe\" \"%~d0%~p0gitk\" %*\nthan the current hardcoded path. (Probably won't work with \ncommand.com, but who uses that for development nowadays anyways, right ;-)\n\n-- \n.marius\n\n"},{"id":"43561","messageId":"465C184F.F6053C0C@eudaptics.com","threadId":"8094","inReplyTo":"465C1252.9020801@trolltech.com","subject":"Re: GIT on MinGW problem","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-29T12:10:55Z","receivedAt":"2007-05-29T12:10:55Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marius Storm-Olsen wrote:\n> \n> Johannes Sixt said the following on 29.05.2007 12:54:\n> > Han-Wen Nienhuys wrote:\n> >> Johannes Sixt escreveu:\n> >>> * git without an correct git subcommand should list 20 or so\n> >>> commands, but it doesn't. The list is just empty.\n> >> there was a problem in generate cmd list, (I have sort in /bin/\n> >> ). I recommend to add\n> >\n> > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the\n> > same as /bin/sort.\n> >\n> > (For the curious ones: The MinGW port has to replace occurrences of\n> > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be\n> > picked up in shell scripts, because the latter usually comes first\n> > in %PATH%^W$PATH. Same for 'find'.)\n> \n> I get that here too, no matter what I set the mount point to be, and\n> without the fstab file at all.\n\nWhen I inserted '/usr/bin/sort' I had checked for 'which sort' on my\nLinux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably\nthe canonical path to sort on any *nix. Will change that. But is this\nalso true for 'find'?\n\n> Also, the /bin/gitk.bat file should rather be\n> @\"%~d0%~p0wish84.exe\" \"%~d0%~p0gitk\" %*\n> than the current hardcoded path. (Probably won't work with\n> command.com, but who uses that for development nowadays anyways, right ;-)\n\nNice trick! But don't try this at home without parental guidance! It\nfills your screen with recursive console window invocations of itself.\n\nI put this into gitk.cmd (didn't try .bat):\n\n@start wish84.exe \"%~d0%~p0gitk\" %*\n\nassuming wish84 is in the PATH (which is probably a sane assumption\nbecause either it is part of the installer, in which case it should have\nset up the PATH, or you have Tcl/Tk installed for some other reason, in\nwhich case you will want to have it in the PATH, too).\n\nFuthermore, I like to have the GUI sent into the background\nautomatically and without opening another console window, hence, the use\nof 'start'.\n\n-- Hannes\n"},{"id":"43562","messageId":"Pine.LNX.4.64.0705291305540.4648@racer.site","threadId":"8094","inReplyTo":"465C1252.9020801@trolltech.com","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-29T12:11:27Z","receivedAt":"2007-05-29T12:11:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 May 2007, Marius Storm-Olsen wrote:\n\n> Johannes Sixt said the following on 29.05.2007 12:54:\n> > Han-Wen Nienhuys wrote:\n> > > Johannes Sixt escreveu:\n> > > > * git without an correct git subcommand should list 20 or so\n> > > > commands, but it doesn't. The list is just empty.\n> > > there was a problem in generate cmd list, (I have sort in /bin/\n> > > ). I recommend to add\n> > \n> > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the\n> > same as /bin/sort.\n> > \n> > (For the curious ones: The MinGW port has to replace occurrences of\n> > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be\n> > picked up in shell scripts, because the latter usually comes first\n> > in %PATH%^W$PATH. Same for 'find'.)\n> \n> I get that here too, no matter what I set the mount point to be, and without\n> the fstab file at all.\n> \n> Also, the /bin/gitk.bat file should rather be\n> @\"%~d0%~p0wish84.exe\" \"%~d0%~p0gitk\" %*\n> than the current hardcoded path. (Probably won't work with command.com, but\n> who uses that for development nowadays anyways, right ;-)\n\nWe're open source, so we _can_ do better than leaving people stuck on \nolder hardware behind.\n\nAnd I don't know what this garbage means. (I checked with GMane, and it \nlooks the same there.) I'd rather have something readable, even if it is \nslightly slower or has to be adjusted when installing.\n\nCiao,\nDscho\n"},{"id":"43564","messageId":"465C2516.7040607@trolltech.com","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705291305540.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-05-29T13:05:26Z","receivedAt":"2007-05-29T13:05:26Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin said the following on 29.05.2007 14:11:\n>> Also, the /bin/gitk.bat file should rather be \n>> @\"%~d0%~p0wish84.exe\" \"%~d0%~p0gitk\" %* than the current\n>> hardcoded path. (Probably won't work with command.com, but who\n>> uses that for development nowadays anyways, right ;-)\n> \n> We're open source, so we _can_ do better than leaving people stuck\n> on older hardware behind.\n> \n> And I don't know what this garbage means. (I checked with GMane,\n> and it looks the same there.) I'd rather have something readable,\n> even if it is slightly slower or has to be adjusted when\n> installing.\n\n%~d0 = expands %0 to a drive letter only\n%~p0 = expands %0 to a path only\n\nso, for\n C:\\foo\\bar\\baz\\gitk.bat\n%~d0%~p0gitk would expand to\n C:\\foo\\bar\\baz\\gitk\n\nLooking at the docs for cmd's call (run 'help call'), I see now that \nit can be written\n %~dp0gitk\nas well..\n\nAnyways, if people are critical to not supporting the command.com, \nthen you could do something like the following. (Note that for \ncommand.com it would be the old behavior were you need to replace the \npath if you install Git somewhere else, while for cmd.exe users it \nwill just work. I'm sure magic can be done to make it work with \ncommand.com as well, but I'll leave that up to someone else to play with):\n\n---\n@echo off\nREM This GOTO relies on the hack that command.com only supports\nREM 8 character labels, so it reads 'goto _Windows'\ngoto :_WindowsNT\n\nREM Command.com jumps here\n:_Windows\nwish84.exe \"C:\\Git\\usr\\bin\\gitk\" %1 %2 %3 %4 %5 %6 %7 %8 %9\nREM NOTE! If you install Git in some other path, and use\nREM command.com, you need to replace the path above\n\ngoto :EOF\n\nREM Cmd.exe jumps here\n:_WindowsNT\nstart wish84.exe \"%~dp0gitk\" %*\n\n:EOF\n\n-- \n.marius\n\n"},{"id":"43565","messageId":"465C2999.677860A6@eudaptics.com","threadId":"8094","inReplyTo":"465C2516.7040607@trolltech.com","subject":"Re: GIT on MinGW problem","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-29T13:24:41Z","receivedAt":"2007-05-29T13:24:41Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marius Storm-Olsen wrote:\n> \n> Johannes Schindelin said the following on 29.05.2007 14:11:\n> >> Also, the /bin/gitk.bat file should rather be\n> >> @\"%~d0%~p0wish84.exe\" \"%~d0%~p0gitk\" %* than the current\n> >> hardcoded path. (Probably won't work with command.com, but who\n> >> uses that for development nowadays anyways, right ;-)\n> >\n> > We're open source, so we _can_ do better than leaving people stuck\n> > on older hardware behind.\n> >\n> > And I don't know what this garbage means. (I checked with GMane,\n> > and it looks the same there.) I'd rather have something readable,\n> > even if it is slightly slower or has to be adjusted when\n> > installing.\n> \n> %~d0 = expands %0 to a drive letter only\n> %~p0 = expands %0 to a path only\n> \n> so, for\n> C:\\foo\\bar\\baz\\gitk.bat\n> %~d0%~p0gitk would expand to\n> C:\\foo\\bar\\baz\\gitk\n> \n> Looking at the docs for cmd's call (run 'help call'), I see now that\n> it can be written\n> %~dp0gitk\n> as well..\n\nBut... the docs also say that this stuff is only available if command\nextensions are turned on. Are they on by default?\n\n(I cannot tell because I remember faintly that I fiddled with the\ncorresponding registry setting in the past, but don't know whether it\nwas on or off at the beginning.)\n\n-- Hannes\n"},{"id":"43566","messageId":"Pine.LNX.4.64.0705291446170.4648@racer.site","threadId":"8094","inReplyTo":"465C2516.7040607@trolltech.com","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-29T13:47:55Z","receivedAt":"2007-05-29T13:47:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 May 2007, Marius Storm-Olsen wrote:\n\n> Looking at the docs for cmd's call (run 'help call'), [...]\n\nWhich one?\n\nThere are at least three different cmd.exe that _I_ encountered: NT4.0, \n2000 and XP. All of them have different features. None of my scripts \nworked without _heavy_ workarounding on all of them.\n\nBut I think a .lnk file would be easier to create, and more portable, \nright?\n\nCiao,\nDscho\n"},{"id":"43567","messageId":"465C3502.BE134BC9@eudaptics.com","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705291446170.4648@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-29T14:13:22Z","receivedAt":"2007-05-29T14:13:22Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin wrote:\n> There are at least three different cmd.exe that _I_ encountered: NT4.0,\n> 2000 and XP. All of them have different features. None of my scripts\n> worked without _heavy_ workarounding on all of them.\n> \n> But I think a .lnk file would be easier to create, and more portable,\n> right?\n\nIf:\n\n1. there is a .lnk file named gitk.lnk with target for example:\n\n D:\\MSYS\\1.0\\mingw\\bin\\wish84.exe D:\\MSYS\\1.0\\git\\bin\\gitk\n\n2. you change PATHEXT to include '.LNK'.\n\nthen gitk can be invoked with varying arguments from CMD. I've tested\nthis only on W2k. Point 2 looks hackish and dangerous to me.\n\n-- Hannes\n"},{"id":"43568","messageId":"f329bf540705290729q18b8ed10t5e61a65b75d3759@mail.gmail.com","threadId":"8094","inReplyTo":"465C184F.F6053C0C@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwenn@gmail.com","sentAt":"2007-05-29T14:29:42Z","receivedAt":"2007-05-29T14:29:42Z","isPatch":false,"sender":{"key":"hanwenn@gmail.com","avatar":"https://gravatar.com/avatar/058832acb8d613baeb6ce9d21b009d9772424a309b9a521330423daef909a27a?d=mp&s=160"},"body":"2007/5/29, Johannes Sixt :\n\n> > I get that here too, no matter what I set the mount point to be, and\n> > without the fstab file at all.\n>\n> When I inserted '/usr/bin/sort' I had checked for 'which sort' on my\n> Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably\n> the canonical path to sort on any *nix. Will change that. But is this\n> also true for 'find'?\n\n\nI suggest that you add $PATH appropriately (prepending /bin and\n/usr/bin/ ) and then\nlet the OS figure it out. The other option is to write an autoconf\ntest to discover the proper path.\n\n\n> > Also, the /bin/gitk.bat file should rather be\n> > @\"%~d0%~p0wish84.exe\" \"%~d0%~p0gitk\" %*\n> > than the current hardcoded path. (Probably won't work with\n> > command.com, but who uses that for development nowadays anyways, right ;-)\n>\n> Nice trick! But don't try this at home without parental guidance! It\n> fills your screen with recursive console window invocations of itself.\n>\n> I put this into gitk.cmd (didn't try .bat):\n>\n> @start wish84.exe \"%~d0%~p0gitk\" %*\n>\n> assuming wish84 is in the PATH (which is probably a sane assumption\n> because either it is part of the installer, in which case it should have\n> set up the PATH, or you have Tcl/Tk installed for some other reason, in\n> which case you will want to have it in the PATH, too).\n>\n> Futhermore, I like to have the GUI sent into the background\n> automatically and without opening another console window, hence, the use\n> of 'start'.\n\nI'll have a look at this when I have time. What the hell is\n\n%~d0%~p0\n\n?\n\n-- \nHan-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43569","messageId":"465C3A88.3090606@trolltech.com","threadId":"8094","inReplyTo":"465C2999.677860A6@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-05-29T14:36:56Z","receivedAt":"2007-05-29T14:36:56Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Sixt said the following on 29.05.2007 15:24:\n>> Looking at the docs for cmd's call (run 'help call'), I see now that\n>> it can be written\n>> %~dp0gitk\n>> as well..\n> \n> But... the docs also say that this stuff is only available if command\n> extensions are turned on. Are they on by default?\n> \n> (I cannot tell because I remember faintly that I fiddled with the\n> corresponding registry setting in the past, but don't know whether it\n> was on or off at the beginning.)\n\nOk, MSDN says it on by default on XP, while other docs say its on by\ndefault without specifying any platforms. Also, it might be that the\n%~dp0 construct is only supported on later versions of the cmd\nextension too (I don't have NT 4, so I can't test this), so to be on\nthe safe side you can do this:\n\n----\n@echo off\nREM This GOTO relies on the hack that command.com only supports\nREM 8 character labels, so it reads 'goto _Windows'\ngoto :_WindowsNT\n\nREM Command.com jumps here\n:_Windows\nwish84.exe \"C:\\Git\\usr\\bin\\gitk\" %1 %2 %3 %4 %5 %6 %7 %8 %9\nREM NOTE! If you install Git in some other path, and use\nREM command.com, you need to replace the path above\n\ngoto :EOF\n\nREM Cmd.exe jumps here\n:_WindowsNT\nif \"%1\" neq \"ensureExt\" (\n REM Call the script again with cmd /X to explicitly turn on Command Extensions\n %COMSPEC% /X /C \"%0 ensureExt %*\"\n goto :EOF\n)\n\nREM If our CMD Extension version is less than 2, we might not support the %~dp0\nREM construct so, just do the normal _Windows call instead. (This should only\nREM happen on old Windows NT 4, where the extension is not so sophisticated\nif not cmdextversion 2 (\n call :_Windows %2 %3 %4 %5 %6 %7 %8 %9\n goto :EOF\n)\nstart wish84.exe \"%~dp0gitk\" %2 %3 %4 %5 %6 %7 %8 %9\n\n:EOF\n\n-- \n.marius\n\n"},{"id":"43570","messageId":"465C3D7B.4364961C@eudaptics.com","threadId":"8094","inReplyTo":"f329bf540705290729q18b8ed10t5e61a65b75d3759@mail.gmail.com","subject":"Re: GIT on MinGW problem","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-29T14:49:31Z","receivedAt":"2007-05-29T14:49:31Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Han-Wen Nienhuys wrote:\n> \n> 2007/5/29, Johannes Sixt :\n> \n> > > I get that here too, no matter what I set the mount point to be, and\n> > > without the fstab file at all.\n> >\n> > When I inserted '/usr/bin/sort' I had checked for 'which sort' on my\n> > Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably\n> > the canonical path to sort on any *nix. Will change that. But is this\n> > also true for 'find'?\n> \n> I suggest that you add $PATH appropriately (prepending /bin and\n> /usr/bin/ ) and then\n> let the OS figure it out. The other option is to write an autoconf\n> test to discover the proper path.\n\n'sort' (and 'find' for that matter) is not only used by the build\nscripts, but also by some shell scripts of the toolset. Hence, the path\nwould have to be modified for each 'git foo' invocation, IOW, by git.exe\nitself. I don't like this solution.\n\nThe alternative, to force the user to put his $MSYSDIR/bin before $WINNT\n(which would require admin rights, btw, because the system's PATH must\nbe modified), I like even less.\n\nI've to think a bit more about this.\n\n-- Hannes\n"},{"id":"43572","messageId":"fcaeb9bf0705290828j3703cfa9g11f2f7afb17a8c91@mail.gmail.com","threadId":"8094","inReplyTo":"465C3502.BE134BC9@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-05-29T15:28:42Z","receivedAt":"2007-05-29T15:28:42Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 5/29/07, Johannes Sixt wrote:\n> Johannes Schindelin wrote:\n> > There are at least three different cmd.exe that _I_ encountered: NT4.0,\n> > 2000 and XP. All of them have different features. None of my scripts\n> > worked without _heavy_ workarounding on all of them.\n> >\n> > But I think a .lnk file would be easier to create, and more portable,\n> > right?\n>\n> If:\n>\n> 1. there is a .lnk file named gitk.lnk with target for example:\n>\n> D:\\MSYS\\1.0\\mingw\\bin\\wish84.exe D:\\MSYS\\1.0\\git\\bin\\gitk\n>\n> 2. you change PATHEXT to include '.LNK'.\n>\n> then gitk can be invoked with varying arguments from CMD. I've tested\n> this only on W2k. Point 2 looks hackish and dangerous to me.\n\nI'd suggest create a small C wrapper to launch gitk. It would be much\neasier that way IMHO.\n\n-- \nDuy\n"},{"id":"43573","messageId":"465C4B0E.C34795B@eudaptics.com","threadId":"8094","inReplyTo":"fcaeb9bf0705290828j3703cfa9g11f2f7afb17a8c91@mail.gmail.com","subject":"Re: GIT on MinGW problem","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-29T15:47:26Z","receivedAt":"2007-05-29T15:47:26Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n> I'd suggest create a small C wrapper to launch gitk. It would be much\n> easier that way IMHO.\n\nDoh! You're right! It's even there already, right before our eyes:\n\npointy..clicky..pointy..clicky (aka: cp gitk git-k)\n\n$ git k\n\n:)\n\n-- Hannes\n"},{"id":"43580","messageId":"fcaeb9bf0705291145q6a0d276o6a94ded3c3e0b6d1@mail.gmail.com","threadId":"8094","inReplyTo":"465C4B0E.C34795B@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-05-29T18:45:35Z","receivedAt":"2007-05-29T18:45:35Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 5/29/07, Johannes Sixt wrote:\n> Nguyen Thai Ngoc Duy wrote:\n> > I'd suggest create a small C wrapper to launch gitk. It would be much\n> > easier that way IMHO.\n>\n> Doh! You're right! It's even there already, right before our eyes:\n>\n> pointy..clicky..pointy..clicky (aka: cp gitk git-k)\n>\n> $ git k\n>\n> :)\n\nMaybe we should teach git.c to try gitk if git-k is not found ;)\n\n> -- Hannes\n>\n>\n\n\n-- \nDuy\n"},{"id":"43597","messageId":"465CDE61.40103@xs4all.nl","threadId":"8094","inReplyTo":"465C4B0E.C34795B@eudaptics.com","subject":"Re: GIT on MinGW problem","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-05-30T02:16:01Z","receivedAt":"2007-05-30T02:16:01Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Sixt escreveu:\n>> I'd suggest create a small C wrapper to launch gitk. It would be much\n>> easier that way IMHO.\n> \n> Doh! You're right! It's even there already, right before our eyes:\n> \n> pointy..clicky..pointy..clicky (aka: cp gitk git-k)\n> \n> $ git k\n> \n> :)\n\nhow about \n\n git tk \n\nthat's more in line what actually happens. We can ship a gitk.bat\nthat runs git-tk.\n\nBTW, I got one report that gitk doesn't work with the tcl/tk that I\nship. Can I have other reports too? ie. \n\n \"It doesn't work for me, I use windows 92\" \n \"It works for me, I use windows QZ\" \n\netc.?\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"43600","messageId":"Pine.LNX.4.64.0705300337510.4011@racer.site","threadId":"8094","inReplyTo":"465CDE61.40103@xs4all.nl","subject":"Re: GIT on MinGW problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-30T02:39:08Z","receivedAt":"2007-05-30T02:39:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 May 2007, Han-Wen Nienhuys wrote:\n\n> Johannes Sixt escreveu:\n> >> I'd suggest create a small C wrapper to launch gitk. It would be much\n> >> easier that way IMHO.\n> > \n> > Doh! You're right! It's even there already, right before our eyes:\n> > \n> > pointy..clicky..pointy..clicky (aka: cp gitk git-k)\n> > \n> > $ git k\n> > \n> > :)\n> \n> how about \n> \n> git tk \n> \n> that's more in line what actually happens. We can ship a gitk.bat\n> that runs git-tk.\n> \n> BTW, I got one report that gitk doesn't work with the tcl/tk that I\n> ship. Can I have other reports too? ie. \n> \n> \"It doesn't work for me, I use windows 92\" \n\nIt worked for me, using Windows XP. (But I don't remember if I had to do \nsome adjustments for it, or only for git-gui.)\n\nBTW Almost any operation I run in git-gui fails, because cat is not found.\n\nCiao,\nDscho\n"},{"id":"43602","messageId":"20070530025705.GN7044@spearce.org","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705300337510.4011@racer.site","subject":"Re: GIT on MinGW problem","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-30T02:57:05Z","receivedAt":"2007-05-30T02:57:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> \n> BTW Almost any operation I run in git-gui fails, because cat is\n> not found.\n\nThat's the stuff that goes into a console and dumps both to\nstdout and stderr. E.g. fetch, push, \"compress database\".\n\nThe issue is Tcl doesn't give me a way to get a pipe to both stdout\nand stderr. I cannot get two pipes, nor can I get a single pipe\nwith both stdout+stderr redirected to that pipe. Unless I pipe\nit into another process. Enter `cat`.\n\nWould we consider a \"--stderr-to-stdout\" long option to git itself?\nThen I could have git-gui do:\n\n\tgit --stderr-to-stdout fetch\n\nand bypass the pipe into cat. Yes, I know, its crap. Welcome to\nTcl.\n\n-- \nShawn.\n"},{"id":"43603","messageId":"Pine.LNX.4.64.0705300402050.4011@racer.site","threadId":"8094","inReplyTo":"fcaeb9bf0705291145q6a0d276o6a94ded3c3e0b6d1@mail.gmail.com","subject":"[PATCH] Make git-k an alias to gitk","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-30T03:03:53Z","receivedAt":"2007-05-30T03:03:53Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nSigned-off-by: Johannes Schindelin \n---\n\nOn Tue, 29 May 2007, Nguyen Thai Ngoc Duy wrote:\n\n\t> On 5/29/07, Johannes Sixt wrote:\n\t> > Nguyen Thai Ngoc Duy wrote:\n\t> > > I'd suggest create a small C wrapper to launch gitk. It \n\t> > > would be much easier that way IMHO.\n\t> > \n\t> > Doh! You're right! It's even there already, right before our \n\t> > eyes:\n\t> > \n\t> > pointy..clicky..pointy..clicky (aka: cp gitk git-k)\n\t> > \n\t> > $ git k\n\t> > \n\t> > :)\n\t> \n\t> Maybe we should teach git.c to try gitk if git-k is not found ;)\n\n\tSomething like this?\n\n Makefile | 2 +-\n git.c | 6 ++++++\n 2 files changed, 7 insertions(+), 1 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 5f94630..01ab1ff 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -262,7 +262,7 @@ EXTRA_PROGRAMS =\n BUILT_INS = \\\n \tgit-format-patch$X git-show$X git-whatchanged$X git-cherry$X \\\n \tgit-get-tar-commit-id$X git-init$X git-repo-config$X \\\n-\tgit-fsck-objects$X git-cherry-pick$X \\\n+\tgit-fsck-objects$X git-cherry-pick$X git-k$X \\\n \t$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))\n \n # what 'all' will build and 'install' will install, in gitexecdir\ndiff --git a/git.c b/git.c\nindex 04eb344..53d81e9 100644\n--- a/git.c\n+++ b/git.c\n@@ -216,6 +216,11 @@ static int handle_alias(int *argcp, const char ***argv)\n \treturn ret;\n }\n \n+static int cmd_gitk(int argc, const char **argv, const char *prefix)\n+{\n+\treturn execv(\"gitk\", (char *const *)argv);\n+}\n+\n const char git_version_string[] = GIT_VERSION;\n \n #define RUN_SETUP\t(1<<0)\n@@ -274,6 +279,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)\n \t\t{ \"help\", cmd_help },\n \t\t{ \"init\", cmd_init_db },\n \t\t{ \"init-db\", cmd_init_db },\n+\t\t{ \"k\", cmd_gitk },\n \t\t{ \"log\", cmd_log, RUN_SETUP | USE_PAGER },\n \t\t{ \"ls-files\", cmd_ls_files, RUN_SETUP },\n \t\t{ \"ls-tree\", cmd_ls_tree, RUN_SETUP },\n-- \n1.5.2.2641.g404de-dirty\n"},{"id":"43605","messageId":"Pine.LNX.4.64.0705300407170.4011@racer.site","threadId":"8094","inReplyTo":"20070530025705.GN7044@spearce.org","subject":"[PATCH] Git wrapper: add --redirect-stderr option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-30T03:25:57Z","receivedAt":"2007-05-30T03:25:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWith this option, stderr is redirected to stdout. The short option is '-2'.\n\nAlternatively, you can say '--redirect-stderr=' to redirect\nstderr to a file.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Tue, 29 May 2007, Shawn O. Pearce wrote:\n\n\t> Johannes Schindelin wrote:\n\t> > \n\t> > BTW Almost any operation I run in git-gui fails, because cat \n\t> > is not found.\n\t> \n\t> That's the stuff that goes into a console and dumps both to\n\t> stdout and stderr. E.g. fetch, push, \"compress database\".\n\t> \n\t> The issue is Tcl doesn't give me a way to get a pipe to both \n\t> stdout and stderr. I cannot get two pipes, nor can I get a \n\t> single pipe with both stdout+stderr redirected to that pipe. \n\t> Unless I pipe it into another process. Enter `cat`.\n\t> \n\t> Would we consider a \"--stderr-to-stdout\" long option to git \n\t> itself? Then I could have git-gui do:\n\t> \n\t> \tgit --stderr-to-stdout fetch\n\t> \n\t> and bypass the pipe into cat. Yes, I know, its crap. Welcome \n\t> to Tcl.\n\n\tHow about this?\n\n git.c | 14 ++++++++++++++\n 1 files changed, 14 insertions(+), 0 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex 53d81e9..72e0539 100644\n--- a/git.c\n+++ b/git.c\n@@ -82,6 +82,20 @@ static int handle_options(const char*** argv, int* argc)\n \t\t} else if (!strcmp(cmd, \"--bare\")) {\n \t\t\tstatic char git_dir[PATH_MAX+1];\n \t\t\tsetenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 1);\n+\t\t} else if (!strcmp(cmd, \"-2\") ||\n+\t\t\t\t!strcmp(cmd, \"--redirect-stderr\")) {\n+\t\t\tif (dup2(1, 2) < 0)\n+\t\t\t\treturn error(\"Could not redirect stderr: %s\",\n+\t\t\t\t\tstrerror(errno));\n+\t\t} else if (!prefixcmp(cmd, \"--redirect-stderr=\")) {\n+\t\t\tint fd = open(cmd + 18, O_WRONLY | O_CREAT, 0777), ret;\n+\t\t\tif (fd < 0)\n+\t\t\t\treturn error(\"Could not open %s\", cmd + 18);\n+\t\t\tret = dup2(fd, 2);\n+\t\t\tclose(fd);\n+\t\t\tif (ret < 0)\n+\t\t\t\treturn error(\"Could not redirect stderr: %s\",\n+\t\t\t\t\tstrerror(errno));\n \t\t} else {\n \t\t\tfprintf(stderr, \"Unknown option: %s\\n\", cmd);\n \t\t\tusage(git_usage_string);\n-- \n1.5.2.2642.gc8bae-dirty\n"},{"id":"43606","messageId":"20070530033830.GO7044@spearce.org","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705300407170.4011@racer.site","subject":"Re: [PATCH] Git wrapper: add --redirect-stderr option","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-30T03:38:30Z","receivedAt":"2007-05-30T03:38:30Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> \n> With this option, stderr is redirected to stdout. The short option is '-2'.\n> \n> Alternatively, you can say '--redirect-stderr=' to redirect\n> stderr to a file.\n\nYes, that works nicely. ;-)\n\nNow here's my other problem: How does git-gui know the underlying\ngit will accept --redirect-stderr? Or that it supports any other\nrecent features we've developed?\n\nSure I can check the version, but until I know what version of Git\nits shipping in I cannot put the check into git-gui.\n\nI was thinking about adding a \"git-supported-features\" plumbing\ncommand that prints back feature code strings, much as our\nnetwork protocol supplies back the few feature codes it supports\n(\"multi-ack\", \"sideband\", etc.). E.g.:\n\n $ git supported-features\n redirect-stderr\n ...\n\nThat way higher level Porcelain can poll the plumbing to see what\nis available, and what isn't.\n\n-- \nShawn.\n"},{"id":"43607","messageId":"Pine.LNX.4.64.0705300444020.4011@racer.site","threadId":"8094","inReplyTo":"20070530033830.GO7044@spearce.org","subject":"Re: [PATCH] Git wrapper: add --redirect-stderr option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-30T03:45:36Z","receivedAt":"2007-05-30T03:45:36Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 May 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > With this option, stderr is redirected to stdout. The short option is '-2'.\n> > \n> > Alternatively, you can say '--redirect-stderr=' to redirect\n> > stderr to a file.\n> \n> Yes, that works nicely. ;-)\n> \n> Now here's my other problem: How does git-gui know the underlying\n> git will accept --redirect-stderr? Or that it supports any other\n> recent features we've developed?\n\nI thought that git-gui is now really closely coupled with core-git.\n\n> Sure I can check the version, but until I know what version of Git\n> its shipping in I cannot put the check into git-gui.\n> \n> I was thinking about adding a \"git-supported-features\" plumbing\n> command that prints back feature code strings, much as our\n> network protocol supplies back the few feature codes it supports\n> (\"multi-ack\", \"sideband\", etc.).\n\nProblem is: it would be more interesting to have this program in _older_ \nversions... ;-)\n\nCiao,\nDscho\n"},{"id":"43608","messageId":"20070530035335.GP7044@spearce.org","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705300444020.4011@racer.site","subject":"Re: [PATCH] Git wrapper: add --redirect-stderr option","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-30T03:53:35Z","receivedAt":"2007-05-30T03:53:35Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Tue, 29 May 2007, Shawn O. Pearce wrote:\n> \n> > Johannes Schindelin wrote:\n> > > \n> > > With this option, stderr is redirected to stdout. The short option is '-2'.\n> > > \n> > > Alternatively, you can say '--redirect-stderr=' to redirect\n> > > stderr to a file.\n> > \n> > Yes, that works nicely. ;-)\n> > \n> > Now here's my other problem: How does git-gui know the underlying\n> > git will accept --redirect-stderr? Or that it supports any other\n> > recent features we've developed?\n> \n> I thought that git-gui is now really closely coupled with core-git.\n\nNot really. It requires 1.5.0 and later, but after that it should\nbe OK with any 1.5.x version of Git. Junio graciously bundles it\nwith core Git, to help it get a wider audience. ;-)\n\nHowever I'd like to let it be smarter about what it expects from the\nunderling core Git. I'm sure the other Porcelain authors would also\nlike to be able to determine if they can rely on something, or not.\nAt the least we can just tell the user \"Your Git old. Upgrade to new\nGit today!\". Yes, bad Engrish included... ;-)\n \n> > Sure I can check the version, but until I know what version of Git\n> > its shipping in I cannot put the check into git-gui.\n> > \n> > I was thinking about adding a \"git-supported-features\" plumbing\n> > command that prints back feature code strings, much as our\n> > network protocol supplies back the few feature codes it supports\n> > (\"multi-ack\", \"sideband\", etc.).\n> \n> Problem is: it would be more interesting to have this program in _older_ \n> versions... ;-)\n\nLack of git-supported-features means only features before it coming\ninto existance? ;-)\n\n-- \nShawn.\n"},{"id":"43609","messageId":"Pine.LNX.4.64.0705300510450.4011@racer.site","threadId":"8094","inReplyTo":"20070530035335.GP7044@spearce.org","subject":"Re: [PATCH] Git wrapper: add --redirect-stderr option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-30T04:12:03Z","receivedAt":"2007-05-30T04:12:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 May 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > On Tue, 29 May 2007, Shawn O. Pearce wrote:\n> > \n> > > Johannes Schindelin wrote:\n> > > > \n> > > > With this option, stderr is redirected to stdout. The short option is '-2'.\n> > > > \n> > > > Alternatively, you can say '--redirect-stderr=' to redirect\n> > > > stderr to a file.\n> > > \n> > > Yes, that works nicely. ;-)\n> > > \n> > > Now here's my other problem: How does git-gui know the underlying\n> > > git will accept --redirect-stderr? Or that it supports any other\n> > > recent features we've developed?\n> > \n> > I thought that git-gui is now really closely coupled with core-git.\n> \n> Not really. It requires 1.5.0 and later, but after that it should\n> be OK with any 1.5.x version of Git. Junio graciously bundles it\n> with core Git, to help it get a wider audience. ;-)\n> \n> However I'd like to let it be smarter about what it expects from the\n> underling core Git. I'm sure the other Porcelain authors would also\n> like to be able to determine if they can rely on something, or not.\n> At the least we can just tell the user \"Your Git old. Upgrade to new\n> Git today!\". Yes, bad Engrish included... ;-)\n\nWhen in doubt, you can always test the return value to check if the \ncommand line option is accepted...\n\nCiao,\nDscho\n"},{"id":"43624","messageId":"465D2272.3383501C@eudaptics.com","threadId":"8094","inReplyTo":"Pine.LNX.4.64.0705300402050.4011@racer.site","subject":"Re: [PATCH] Make git-k an alias to gitk","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-30T07:06:26Z","receivedAt":"2007-05-30T07:06:26Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin wrote:\n> \n> Signed-off-by: Johannes Schindelin \n> ---\n> \n> On Tue, 29 May 2007, Nguyen Thai Ngoc Duy wrote:\n> \n> > On 5/29/07, Johannes Sixt wrote:\n> > > pointy..clicky..pointy..clicky (aka: cp gitk git-k)\n> > >\n> > > $ git k\n> > >\n> > > :)\n> >\n> > Maybe we should teach git.c to try gitk if git-k is not found ;)\n> \n> Something like this?\n> \n> +static int cmd_gitk(int argc, const char **argv, const char *prefix)\n> +{\n> + return execv(\"gitk\", (char *const *)argv);\n> +}\n> +\n\nThis does not work. Windows's execv() does not know how to invoke shell\n(or tcl) scripts. Only execve() does, because we have our own\nimplementation.\n\nI'd prefer to install gitk under both names gitk and git-k (as hard\nlinks; which would amount to copies on Windows, but we don't care).\n\n-- Hannes\n"}]}