{"thread":{"id":"32189","subject":"Python extension commands in git - request for policy change","startedAt":"2012-11-25T02:44:51Z","lastAt":"2012-12-19T02:30:22Z","messageCount":82,"participants":["Eric S. Raymond","Nguyen Thai Ngoc Duy","Felipe Contreras","Johannes Sixt","Pat Thoyts","Michael Haggerty","David Lang","Stefano Lattarini","Erik Faye-Lund","Johannes Schindelin","Krzysztof Mazur","Sitaram Chamarty","Andreas Ericsson","David Aguilar","Magnus Bäck","Guillaume DE BURE","Jeff King","Joshua Jensen","Philippe Vaucher","Stephen Bash","Martin Langhoff","Patrick Donnelly","Tomas Carnecky","Junio C Hamano","Andrew Ardill"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203772","messageId":"20121125024451.1ADD14065F@snark.thyrsus.com","threadId":"32189","inReplyTo":null,"subject":"Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T02:44:51Z","receivedAt":"2012-11-25T02:44:51Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"git presently contains one Python extension command, Pete Wycoff's p4\nimporter.  If my git-weave code is merged it will acquire another.  \nI think we can expect more submissions of Python extensions in the\nfuture, for two good reasons:\n\n1. Python has a much richer type ontology than shell; there are many\nthings this makes relatively easy that are quite painful in shell.\n\n2. While Perl shares advantage #1, compared to Python it's a\nmaintainability mess - much more difficult to read 6 months later.\n\nOn the other hand, \n\n3. Attitudes in the git dev group seem to be influenced by a\nperception that up-to-date Python versions are not as reliably present\non our target platforms as Perl is.\n\n4. Python has the disadvantage that comes with robust growth; you have\nto specify \"version x.y or later\" as a dependency, mainly because new\nmodules keep getting getting folded into the stock Python environment.\n\nPrevious conversation on the list suggests that there has been a tacit\npolicy of managing these problems by (a) discouraging (though not entirely\nforbidding) Python extensions, and (b) requiring extension submitters to\ndocument some dependency on language version.\n\nI think this is suboptimal.  By not forbidding the Python language\nentirely, we guarantee having to deal with problems 3 and 4 anyway -\nbut by discouraging it, we're buying significant long-term\nmaintainability costs. It especially disturbed me to hear of Python\ncommands being recoded in C - that is definitely not the right\ndirection for reducing expected defect counts, if only because of\nmemory-management issues.\n\nWe're behind the best-practices curve here.  The major Linux\ndistributions, which have to deal with almost the same set of\ntradeoffs we do, went to Python for pretty much all glue and\nadministration scripts outside /etc a decade ago, and the decision has\nserved them well.\n\nThat, among other things, means up-to-date versions of Python are\nubiquitous unless we're looking at Windows - in which case Perl and\nshell actually become much bigger portability problems.  Mac OS X \nhas kept up to date, too; Lion shipped 2.7.1 and that was a major\nrelease back at this point.\n\nTo be fair, there was a time when being a bit twitchy about Python\nversion skew and deployment breadth was justified, but I believe that\ntime is now well past us. My basis for believing this is very simple -\nI maintain a lot of Python code for systems programmers with stiff\nportability requirements (things like reposurgeon, coverity-submit,\nfreecode-submit, shipper, and the Python tools in gpsd). I know what\nkinds of bug reports I get and what kinds I don't, and in the last\nfew years \"this breaks on my Python version\" has gone from unusual\nto doesn't-happen.\n\nI think my experience with gpsd is particularly instructive.  Like\ngit, that project has a C core with Python wrappers and extension \ncomponents. Like git, it gets deployed in a lot of odd places by people\nwho cannot afford the time to be tolerant about cross-platform\nproblems and are quite willing to hit the maintainer with a clue-bat\nwhen they encounter them.  The good news is - they don't have to.\n\nI should also point out that none of Mercurial's problems seem to\nhave anything to do with the fact that it's written in Python...\n\nI think we can choose a better policy based on some simple premises.\n\n1) In 2012, we can specify a \"floor\" Python version of 2.6 (shipped in\n2008) and be pretty much guaranteed it will be anywhere we want to\ndeploy except Windows.  Windows will remain a problem because Python\nisn't part of the stock install, but that's an equal or worse problem\nfor shell and Perl - and at least the Python project ships a binary\ninstaller for Windows.\n\n2) Python extension commands should test the Python version on startup\nand die loudly but gracefully in the rare case that they don't find\nwhat they need.\n\n3) We should be unconditionally be encouraging extensions to move\nfrom shell and Perl to Python.  This would be a clear net gain is\nportability and maintainability.\n\n4) We should be encouraging C code to move to Python, too.  There's\nlittle gain in portability on this path because modern C has cleaned\nup its act a lot, but the drop in expected bug loads would be well\nworth the porting effort.  Segfaults are not your friend, and the x2 to\nx5 drop in line count would do very good things for long-term\nmaintainability.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n\nLive free or die; death is not the worst of evils.\n\t-- General George Stark.\n"},{"id":"203773","messageId":"CACsJy8BbUjrJtfpEvbcK==Y2gFNsFhFBN93CL36J5uVe=Ca4wQ@mail.gmail.com","threadId":"32189","inReplyTo":"20121125024451.1ADD14065F@snark.thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-11-25T03:15:08Z","receivedAt":"2012-11-25T03:15:08Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"CCing msysgit. I vaguely remember they had problems with building\nPython on Windows. I don't know if it's still an issue.\n\nOn Sun, Nov 25, 2012 at 9:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> git presently contains one Python extension command, Pete Wycoff's p4\n> importer.  If my git-weave code is merged it will acquire another.\n> I think we can expect more submissions of Python extensions in the\n> future, for two good reasons:\n>\n> 1. Python has a much richer type ontology than shell; there are many\n> things this makes relatively easy that are quite painful in shell.\n>\n> 2. While Perl shares advantage #1, compared to Python it's a\n> maintainability mess - much more difficult to read 6 months later.\n>\n> On the other hand,\n>\n> 3. Attitudes in the git dev group seem to be influenced by a\n> perception that up-to-date Python versions are not as reliably present\n> on our target platforms as Perl is.\n>\n> 4. Python has the disadvantage that comes with robust growth; you have\n> to specify \"version x.y or later\" as a dependency, mainly because new\n> modules keep getting getting folded into the stock Python environment.\n\nThese may apply to other languages as well. Where do we draw a line?\n\n\n> Previous conversation on the list suggests that there has been a tacit\n> policy of managing these problems by (a) discouraging (though not entirely\n> forbidding) Python extensions, and (b) requiring extension submitters to\n> document some dependency on language version.\n>\n> I think this is suboptimal.  By not forbidding the Python language\n> entirely, we guarantee having to deal with problems 3 and 4 anyway -\n> but by discouraging it, we're buying significant long-term\n> maintainability costs. It especially disturbed me to hear of Python\n> commands being recoded in C - that is definitely not the right\n> direction for reducing expected defect counts, if only because of\n> memory-management issues.\n>\n> We're behind the best-practices curve here.  The major Linux\n> distributions, which have to deal with almost the same set of\n> tradeoffs we do, went to Python for pretty much all glue and\n> administration scripts outside /etc a decade ago, and the decision has\n> served them well.\n>\n> That, among other things, means up-to-date versions of Python are\n> ubiquitous unless we're looking at Windows - in which case Perl and\n> shell actually become much bigger portability problems.  Mac OS X\n> has kept up to date, too; Lion shipped 2.7.1 and that was a major\n> release back at this point.\n>\n> To be fair, there was a time when being a bit twitchy about Python\n> version skew and deployment breadth was justified, but I believe that\n> time is now well past us. My basis for believing this is very simple -\n> I maintain a lot of Python code for systems programmers with stiff\n> portability requirements (things like reposurgeon, coverity-submit,\n> freecode-submit, shipper, and the Python tools in gpsd). I know what\n> kinds of bug reports I get and what kinds I don't, and in the last\n> few years \"this breaks on my Python version\" has gone from unusual\n> to doesn't-happen.\n>\n> I think my experience with gpsd is particularly instructive.  Like\n> git, that project has a C core with Python wrappers and extension\n> components. Like git, it gets deployed in a lot of odd places by people\n> who cannot afford the time to be tolerant about cross-platform\n> problems and are quite willing to hit the maintainer with a clue-bat\n> when they encounter them.  The good news is - they don't have to.\n>\n> I should also point out that none of Mercurial's problems seem to\n> have anything to do with the fact that it's written in Python...\n>\n> I think we can choose a better policy based on some simple premises.\n>\n> 1) In 2012, we can specify a \"floor\" Python version of 2.6 (shipped in\n> 2008) and be pretty much guaranteed it will be anywhere we want to\n> deploy except Windows.  Windows will remain a problem because Python\n> isn't part of the stock install, but that's an equal or worse problem\n> for shell and Perl - and at least the Python project ships a binary\n> installer for Windows.\n>\n> 2) Python extension commands should test the Python version on startup\n> and die loudly but gracefully in the rare case that they don't find\n> what they need.\n>\n> 3) We should be unconditionally be encouraging extensions to move\n> from shell and Perl to Python.  This would be a clear net gain is\n> portability and maintainability.\n>\n> 4) We should be encouraging C code to move to Python, too.  There's\n> little gain in portability on this path because modern C has cleaned\n> up its act a lot, but the drop in expected bug loads would be well\n> worth the porting effort.  Segfaults are not your friend, and the x2 to\n> x5 drop in line count would do very good things for long-term\n> maintainability.\n> --\n>                 <a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n>\n> Live free or die; death is not the worst of evils.\n>         -- General George Stark.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\n\n\n-- \nDuy\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203774","messageId":"20121125051809.GA3670@thyrsus.com","threadId":"32189","inReplyTo":"CACsJy8BbUjrJtfpEvbcK==Y2gFNsFhFBN93CL36J5uVe=Ca4wQ@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T05:18:09Z","receivedAt":"2012-11-25T05:18:09Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Nguyen Thai Ngoc Duy <pclouds@gmail.com>:\n> These may apply to other languages as well. Where do we draw a line?\n\nI'm in favor of the general policy of avoiding scripting languages\nother than the top three most widely deployed.  At the moment that\nmeans shell, Python, Perl; on present trends, in a few years Perl\n(dropping in popularity) might be passed by Ruby on the way up.\n\nOr, to put it another way, I'm *not* actually arguing that we ought\nto encourage extension commands in Guile or Haskell or whatever else\nthe in-language-of-the-week is.  It would be bad for maintainability \nto fragment git's codebase that way.\n\nWhat I'm arguing is that the tradeoffs within the group {C, shell, Perl,\nPython} have changed in ways that favor Python as it has become more\nstable and widely deployed.  So instead of grudgingly allowing a few\nPython extensions in through a back door we ought to be encouraging\nmore use of it.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203780","messageId":"CAMP44s18MzmWRNRiRjL6hvpK1cm=S-97fB2ep-_0RAhnfs5cvA@mail.gmail.com","threadId":"32189","inReplyTo":"20121125024451.1ADD14065F@snark.thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-25T08:53:01Z","receivedAt":"2012-11-25T08:53:01Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> git presently contains one Python extension command, Pete Wycoff's p4\n> importer.  If my git-weave code is merged it will acquire another.\n> I think we can expect more submissions of Python extensions in the\n> future, for two good reasons:\n\nAccording to the Git User Survey 2012, 1% of the responders used the\n'git p4' tool. I don't know how much widely used 'git weave' would be,\nbut I wouldn't want to star changing policies for issues that are\npractically non-existent or irrelevant for the vast majority of git\nusers.\n\n> We're behind the best-practices curve here.  The major Linux\n> distributions, which have to deal with almost the same set of\n> tradeoffs we do, went to Python for pretty much all glue and\n> administration scripts outside /etc a decade ago, and the decision has\n> served them well.\n\nIf your friends jump off a bridge, would you? Yes, using python has\nserved them well, but as opposed to what? Other scripting languages? I\ndon't think so.\n\n> I should also point out that none of Mercurial's problems seem to\n> have anything to do with the fact that it's written in Python...\n\nI agree that the _current_ major problems with mercurial are not\nrelated to python, but once those are solved, who says python won't be\nan issue?. That's an exercise in guesswork, because we can't know.\n\n> I think we can choose a better policy based on some simple premises.\n>\n> 1) In 2012, we can specify a \"floor\" Python version of 2.6 (shipped in\n> 2008) and be pretty much guaranteed it will be anywhere we want to\n> deploy except Windows.  Windows will remain a problem because Python\n> isn't part of the stock install, but that's an equal or worse problem\n> for shell and Perl - and at least the Python project ships a binary\n> installer for Windows.\n\nWhat if my extension only supports python 2.7? Or what if my extension\nwants to support 2.0?\n\n> 2) Python extension commands should test the Python version on startup\n> and die loudly but gracefully in the rare case that they don't find\n> what they need.\n\nYes, they should _if_ they know what version they need. In my\nextensions I really have no idea.\n\n> 3) We should be unconditionally be encouraging extensions to move\n> from shell and Perl to Python.  This would be a clear net gain is\n> portability and maintainability.\n\nNO! It's up to the developer to choose what language to use, and I\nfind it very chauvinist of you to say \"python is better, so let's all\nuse python\". So far you have listed a few advantages of python, but\nyou haven't explained so far what is wrong with shell and perl.\n\nIn fact, while advancing python you have made clear a problem with\npython; the version requirements. So far I have *never* encountered a\nproblem with git because of my bash version, or my perl version. And\nwe haven't touched to the python3 mess yet. To me, those are\nadvantages of shell and perl.\n\nActually, I don't care if 'git foo' is written in perl, or shell, or\nc; as long as it *works*. And I would hate it if 'git rebase' ever\ntold me that I need a newer version of python, or worst; that I don't\nhave python in my system (Arch Linux ships 'python2', not 'python').\n\nAnd what if X developer that wrote Y tool loves perl, and hates\npython? Or loves ruby? Are we going to kick him out of the project\nbecause (s)he refuses to switch to python? Are we going to threat him\nlike an outsider, a rogue developer?\n\n> 4) We should be encouraging C code to move to Python, too.  There's\n> little gain in portability on this path because modern C has cleaned\n> up its act a lot, but the drop in expected bug loads would be well\n> worth the porting effort.  Segfaults are not your friend, and the x2 to\n> x5 drop in line count would do very good things for long-term\n> maintainability.\n\nDefinitely NO! I really really doubt git in python would be able to\nachieve the same performance as git in c, but to show me wrong, it\nwouldn't be very difficult to run a few measurements with python\ndulwich *if* we are even to begin considering this point.\n\nAnd are segmentation faults really that different from python's\nexceptions? Not to the user.\n\nAnd why not ruby instead?\n\nIf you are serious about this, I think there's a lot more to work to\nshow that there's anything wrong with the current situation, and that\nother alternatives (e.g. ruby) are not good solutions. I for one would\nlike to see more tools move away from perl/shell, and into C. And\nother tools move to ruby, but that it's up to the developers of those\ntools, unless I myself do it.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203781","messageId":"CAMP44s0r1J=aOuEpKQ1+ew9FzODwLX-w5z9rG-WN6AjU0o97yw@mail.gmail.com","threadId":"32189","inReplyTo":"20121125051809.GA3670@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-25T08:56:50Z","receivedAt":"2012-11-25T08:56:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Nguyen Thai Ngoc Duy <pclouds@gmail.com>:\n>> These may apply to other languages as well. Where do we draw a line?\n>\n> I'm in favor of the general policy of avoiding scripting languages\n> other than the top three most widely deployed.  At the moment that\n> means shell, Python, Perl; on present trends, in a few years Perl\n> (dropping in popularity) might be passed by Ruby on the way up.\n\nTop three according to whom?\n\nAccording to TIOBE it's python, perl, and ruby (if you don't count VB\nor PHP), and perl is beating ruby only by a small margin that will\nprobably disappear soon. However, shell has advantages none of the\nabove have.\n\nhttp://1.1.1.4/bmi/www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203782","messageId":"50B1DD78.5040907@kdbg.org","threadId":"32189","inReplyTo":"20121125024451.1ADD14065F@snark.thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2012-11-25T08:57:28Z","receivedAt":"2012-11-25T08:57:28Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 25.11.2012 03:44, schrieb Eric S. Raymond:\n> That, among other things, means up-to-date versions of Python are\n> ubiquitous unless we're looking at Windows - in which case Perl and\n> shell actually become much bigger portability problems.\n\nYou seem to ignore that more than a quater of users are on Windows[1].\nThis is not negligible.\n\nTherefore, we *are* looking at Windows. But where is there a portability\nproblem? There is a POSIX shell available in all git installations on\nWindows. So is Perl. Python is not.\n\n[1]\nhttps://git.wiki.kernel.org/index.php/GitSurvey2011#10._On_which_operating_system.28s.29_do_you_use_Git.3F\n\n> 4) We should be encouraging C code to move to Python, too.\n\nAbsolutely not. To achieve best portability, all code should move to C\ninstead.\n\n-- Hannes\n"},{"id":"203785","messageId":"20121125095356.GA22279@thyrsus.com","threadId":"32189","inReplyTo":"CAMP44s18MzmWRNRiRjL6hvpK1cm=S-97fB2ep-_0RAhnfs5cvA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T09:53:56Z","receivedAt":"2012-11-25T09:53:56Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> If your friends jump off a bridge, would you? Yes, using python has\n> served them well, but as opposed to what? Other scripting languages? I\n> don't think so.\n\nThe competition that Python won was *precisely* against other scripting\nlanguages, notably shell and Perl.  Both used to be much more heavily\nused in system scripting than they are now.\n\n> What if my extension only supports python 2.7? Or what if my extension\n> wants to support 2.0?\n\nI propose that if 2.6 can't support it, then that should be considered\ngrounds to reject it.\n\n> Yes, they should _if_ they know what version they need. In my\n> extensions I really have no idea.\n\nThen you shouldn't submit those extensions to be folded into core git.\n\n> > 3) We should be unconditionally be encouraging extensions to move\n> > from shell and Perl to Python.  This would be a clear net gain is\n> > portability and maintainability.\n> \n> NO! It's up to the developer to choose what language to use,\n\nI agree.  You seem to be raising a lot of straw men.  'Encouragement'\ndoes not equate to beating anyone who makes an unpopular choice over\nthe head.\n\nI am also not suggesting that the whole git core ought to be hoicked \nover to Python.  I was thinking mainly about extension subcommands, \nnot what's in libgit now.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203786","messageId":"20121125095429.GB22279@thyrsus.com","threadId":"32189","inReplyTo":"CAMP44s0r1J=aOuEpKQ1+ew9FzODwLX-w5z9rG-WN6AjU0o97yw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T09:54:29Z","receivedAt":"2012-11-25T09:54:29Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> > Nguyen Thai Ngoc Duy <pclouds@gmail.com>:\n> >> These may apply to other languages as well. Where do we draw a line?\n> >\n> > I'm in favor of the general policy of avoiding scripting languages\n> > other than the top three most widely deployed.  At the moment that\n> > means shell, Python, Perl; on present trends, in a few years Perl\n> > (dropping in popularity) might be passed by Ruby on the way up.\n> \n> Top three according to whom?\n\nAccording to the LOC counts in git's codebase.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203789","messageId":"20121125102536.GC22279@thyrsus.com","threadId":"32189","inReplyTo":"50B1DD78.5040907@kdbg.org","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T10:25:36Z","receivedAt":"2012-11-25T10:25:36Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Johannes Sixt <j6t@kdbg.org>:\n> Am 25.11.2012 03:44, schrieb Eric S. Raymond:\n> > That, among other things, means up-to-date versions of Python are\n> > ubiquitous unless we're looking at Windows - in which case Perl and\n> > shell actually become much bigger portability problems.\n> \n> You seem to ignore that more than a quater of users are on Windows[1].\n> This is not negligible.\n\nI'm not ignoring that at all.  There are questions of fact here:\n\nAre Perl and a POSIX shell part of the stock installation of Windows?\nI believe the answer is \"no\".  You are free to correct me, but if that's\ntrue they don't have any obvious portability advantage over Python.\nThat means the 25% percent of Windows users are not actually a reason\nto prefer them.\n\n> Absolutely not. To achieve best portability, all code should move to C\n> instead.\n\nI wrote the (first) book on C portability.  I mean that literally -\n\"Portable C and Unix Systems Programming\", Prentice-Hall 1987.  Please\ndon't feel insulted when I point out that over the last 25 years I\nhave probably forgotten more about this topic than you know.  Just\nlisten when I tell you that it is not at all obvious that raw C is the\nmaximally portable language.\n\nIt may very well be the case that some random scripting language (not\nnecessarily Python) achieves greater portability simply because its\nmaintainers get to pay more concentrated attention to the portability\nof the environment bindings at the bottom of their C implementation than\nwe can.\n\nIn any case, I don't believe the difference in portability between raw\nC and Python is large enough in either direction to be a reason to\nfavor either, and I speak as a domain expert on this issue.  This is\nnot Python advocacy talking; the same could be said of Perl or Ruby.\n\nThe real advantages of a scripting language are in maintainability and\nexpected defect rates, not portability.  The three relevant things we kbnow\nfrom large-scale studies of software defect patterns are these:\n\n1) Expected defect counts are predictable from LOC.\n\n2) Moving to any given scripting language from C dramatically reduces LOC,\nand thus expected defects over time.\n\n3) Moving to any scripting language from C eliminates a class of\nmemory-management problems that dominate C defect statistics.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203788","messageId":"CABNJ2G+CevGU=-DjC073yGv0gupd9QK6eyjhrrQTNNmTkq_fxg@mail.gmail.com","threadId":"32189","inReplyTo":"CACsJy8BbUjrJtfpEvbcK==Y2gFNsFhFBN93CL36J5uVe=Ca4wQ@mail.gmail.com","subject":"Re: Re: Python extension commands in git - request for policy change","fromName":"Pat Thoyts","fromEmail":"patthoyts@gmail.com","sentAt":"2012-11-25T10:26:41Z","receivedAt":"2012-11-25T10:26:41Z","isPatch":false,"sender":{"key":"patthoyts@gmail.com","avatar":"https://gravatar.com/avatar/bee887a777c790bd241f398217723fbe4b854428671db83db32216a28654cb25?d=mp&s=160"},"body":"On 25 November 2012 03:15, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> CCing msysgit. I vaguely remember they had problems with building\n> Python on Windows. I don't know if it's still an issue.\n>\n> On Sun, Nov 25, 2012 at 9:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n>> git presently contains one Python extension command, Pete Wycoff's p4\n>> importer.  If my git-weave code is merged it will acquire another.\n>> I think we can expect more submissions of Python extensions in the\n>> future, for two good reasons:\n>>\n>> 1. Python has a much richer type ontology than shell; there are many\n>> things this makes relatively easy that are quite painful in shell.\n>>\n>> 2. While Perl shares advantage #1, compared to Python it's a\n>> maintainability mess - much more difficult to read 6 months later.\n>>\n>> On the other hand,\n>>\n>> 3. Attitudes in the git dev group seem to be influenced by a\n>> perception that up-to-date Python versions are not as reliably present\n>> on our target platforms as Perl is.\n>>\n>> 4. Python has the disadvantage that comes with robust growth; you have\n>> to specify \"version x.y or later\" as a dependency, mainly because new\n>> modules keep getting getting folded into the stock Python environment.\n>\n> These may apply to other languages as well. Where do we draw a line?\n>\n>\n>> Previous conversation on the list suggests that there has been a tacit\n>> policy of managing these problems by (a) discouraging (though not entirely\n>> forbidding) Python extensions, and (b) requiring extension submitters to\n>> document some dependency on language version.\n>>\n>> I think this is suboptimal.  By not forbidding the Python language\n>> entirely, we guarantee having to deal with problems 3 and 4 anyway -\n>> but by discouraging it, we're buying significant long-term\n>> maintainability costs. It especially disturbed me to hear of Python\n>> commands being recoded in C - that is definitely not the right\n>> direction for reducing expected defect counts, if only because of\n>> memory-management issues.\n>>\n>> We're behind the best-practices curve here.  The major Linux\n>> distributions, which have to deal with almost the same set of\n>> tradeoffs we do, went to Python for pretty much all glue and\n>> administration scripts outside /etc a decade ago, and the decision has\n>> served them well.\n>>\n>> That, among other things, means up-to-date versions of Python are\n>> ubiquitous unless we're looking at Windows - in which case Perl and\n>> shell actually become much bigger portability problems.  Mac OS X\n>> has kept up to date, too; Lion shipped 2.7.1 and that was a major\n>> release back at this point.\n>>\n>> To be fair, there was a time when being a bit twitchy about Python\n>> version skew and deployment breadth was justified, but I believe that\n>> time is now well past us. My basis for believing this is very simple -\n>> I maintain a lot of Python code for systems programmers with stiff\n>> portability requirements (things like reposurgeon, coverity-submit,\n>> freecode-submit, shipper, and the Python tools in gpsd). I know what\n>> kinds of bug reports I get and what kinds I don't, and in the last\n>> few years \"this breaks on my Python version\" has gone from unusual\n>> to doesn't-happen.\n>>\n>> I think my experience with gpsd is particularly instructive.  Like\n>> git, that project has a C core with Python wrappers and extension\n>> components. Like git, it gets deployed in a lot of odd places by people\n>> who cannot afford the time to be tolerant about cross-platform\n>> problems and are quite willing to hit the maintainer with a clue-bat\n>> when they encounter them.  The good news is - they don't have to.\n>>\n>> I should also point out that none of Mercurial's problems seem to\n>> have anything to do with the fact that it's written in Python...\n>>\n>> I think we can choose a better policy based on some simple premises.\n>>\n>> 1) In 2012, we can specify a \"floor\" Python version of 2.6 (shipped in\n>> 2008) and be pretty much guaranteed it will be anywhere we want to\n>> deploy except Windows.  Windows will remain a problem because Python\n>> isn't part of the stock install, but that's an equal or worse problem\n>> for shell and Perl - and at least the Python project ships a binary\n>> installer for Windows.\n>>\n>> 2) Python extension commands should test the Python version on startup\n>> and die loudly but gracefully in the rare case that they don't find\n>> what they need.\n>>\n>> 3) We should be unconditionally be encouraging extensions to move\n>> from shell and Perl to Python.  This would be a clear net gain is\n>> portability and maintainability.\n>>\n>> 4) We should be encouraging C code to move to Python, too.  There's\n>> little gain in portability on this path because modern C has cleaned\n>> up its act a lot, but the drop in expected bug loads would be well\n>> worth the porting effort.  Segfaults are not your friend, and the x2 to\n>> x5 drop in line count would do very good things for long-term\n>> maintainability.\n\nGit for Windows simply ships everything we need to run git - so if a\ndesirable module requires a version of python, we will add that\nversion plus any required modules into the installer. We already have\na patch to provide python in the msysgit tree - it would just require\npolishing up a little. I'm certain this is no problem for the other\nwindows port (cygwin) either.\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203790","messageId":"20121125103316.GA24514@thyrsus.com","threadId":"32189","inReplyTo":"CABNJ2G+CevGU=-DjC073yGv0gupd9QK6eyjhrrQTNNmTkq_fxg@mail.gmail.com","subject":"Re: Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T10:33:17Z","receivedAt":"2012-11-25T10:33:17Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Pat Thoyts <patthoyts@gmail.com>:\n> Git for Windows simply ships everything we need to run git - so if a\n> desirable module requires a version of python, we will add that\n> version plus any required modules into the installer. We already have\n> a patch to provide python in the msysgit tree - it would just require\n> polishing up a little. I'm certain this is no problem for the other\n> windows port (cygwin) either.\n\nThank you - I think this completely disposes of the \"Windows is a blocker\nfor scripting language X\" argument, with the case X = Python in point. \n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203795","messageId":"50B1F684.5020805@alum.mit.edu","threadId":"32189","inReplyTo":"CAMP44s18MzmWRNRiRjL6hvpK1cm=S-97fB2ep-_0RAhnfs5cvA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-11-25T10:44:20Z","receivedAt":"2012-11-25T10:44:20Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 11/25/2012 09:53 AM, Felipe Contreras wrote:\n> On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n>> 1) In 2012, we can specify a \"floor\" Python version of 2.6 (shipped in\n>> 2008) and be pretty much guaranteed it will be anywhere we want to\n>> deploy except Windows.  Windows will remain a problem because Python\n>> isn't part of the stock install, but that's an equal or worse problem\n>> for shell and Perl - and at least the Python project ships a binary\n>> installer for Windows.\n> \n> What if my extension only supports python 2.7? Or what if my extension\n> wants to support 2.0?\n\nThere would obviously have to be a policy like \"all Python code in core\ngit must run on any Python interpreter with 2.6 <= version < 3.0\", just\nas there are policies about what C and shell features are allowed.  If\nyou happen to want to support earlier versions of Python, I don't see\nwhy anybody would stop you as long as your code also runs in the\nmandated versions.\n\n(In practice, backwards compatibility within Python versions 2.x is very\ngood and almost any code that runs in Python 2.6 would automatically run\nin all later 2.x versions.  Moreover, the Python documentation covering\nwhat is available in each version and the deltas between versions is\nhigh-quality and easily available online.)\n\nThere is, of course, the awkward issue of how/when to transition to\nPython 3.x, which is *not* backwards compatible with Python 2.x.  I\nexpect that when the time comes there will be volunteers (myself\nincluded) willing to help adapt Python scripts to the new version, but\nthe problem shouldn't be minimized.\n\nOf course Perl will have the same problem if Perl6 ever materializes.\n\n>> 2) Python extension commands should test the Python version on startup\n>> and die loudly but gracefully in the rare case that they don't find\n>> what they need.\n> \n> Yes, they should _if_ they know what version they need. In my\n> extensions I really have no idea.\n\nThen simply (with the help of the mailing list) ensure that your\nextensions run under 2.6 (or whatever the chosen minimum version is) and\neverything will be OK.  It is not an error to specify 2.6 as the minimum\nversion even though your script happens also to run on older versions :-)\n\n>> 3) We should be unconditionally be encouraging extensions to move\n>> from shell and Perl to Python.  This would be a clear net gain is\n>> portability and maintainability.\n> \n> NO! It's up to the developer to choose what language to use, and I\n> find it very chauvinist of you to say \"python is better, so let's all\n> use python\". So far you have listed a few advantages of python, but\n> you haven't explained so far what is wrong with shell and perl.\n\nGiven that some languages are accepted in git-core and others are not,\nit's already not \"up to the developer to choose what language to use\".\nAt best there is a short list of \"blessed\" languages, and the developer\ncan choose among only those.\n\n> In fact, while advancing python you have made clear a problem with\n> python; the version requirements. So far I have *never* encountered a\n> problem with git because of my bash version, or my perl version. And\n> we haven't touched to the python3 mess yet. To me, those are\n> advantages of shell and perl.\n\nOn the contrary, there is *constant* traffic on the mailing list about\nincompatibilities between different shell implementations (sh, dash,\nbash, etc), not to mention those in other utilities (sed, grep, etc)\nthat one is forced to work with in shell scripts.  Compatibility is a\n*huge* pain when developing shell code for git.  The fact that users\ntypically don't encounter such problems is due to the hard work of POSIX\nlawyers on the mailing list correcting the compatibility errors of\nmortal programmers.\n\n> Actually, I don't care if 'git foo' is written in perl, or shell, or\n> c; as long as it *works*. And I would hate it if 'git rebase' ever\n> told me that I need a newer version of python, or worst; that I don't\n> have python in my system (Arch Linux ships 'python2', not 'python').\n\nThe configure script would locate the correct interpreter and the build\nwould adjust the scripts' shebang lines, just as things are tweaked\nwithin Perl scripts at build time.\n\n>> 4) We should be encouraging C code to move to Python, too.  There's\n>> little gain in portability on this path because modern C has cleaned\n>> up its act a lot, but the drop in expected bug loads would be well\n>> worth the porting effort.  Segfaults are not your friend, and the x2 to\n>> x5 drop in line count would do very good things for long-term\n>> maintainability.\n> \n> Definitely NO! I really really doubt git in python would be able to\n> achieve the same performance as git in c, but to show me wrong, it\n> wouldn't be very difficult to run a few measurements with python\n> dulwich *if* we are even to begin considering this point.\n> \n> And are segmentation faults really that different from python's\n> exceptions? Not to the user.\n\nThere is one huge difference: it C it is all too easy to write code that\nleads to a security hole due to buffer overflows and other memory\nmanagement errors.  Code written in a scripting language are largely\nimmune to such problems (except of course for any such bugs in the\ninterpreter itself, but the testing of the interpreter is shared across\nmany projects and users).\n\nIt would be insane to rewrite performance-critical C code in any\nscripting language, but there is a huge penumbra of code that is not\nperformance critical and that mutates rapidly.  Such code is much easier\nto write and maintain in a sane scripting language if the portability\nissues can be mastered.\n\nThe most important issues to consider when imagining a future with a\nhybrid of code in C and some scripting language \"X\" are:\n\n* Portability: is \"X\" available on all platforms targeted by git, in\n  usable and mutually-compatible versions?\n\n* Startup time: Is the time to start the \"X\" interpreter prohibitive?\n  (On my computer, \"python -c pass\", which starts the Python\n  interpreter and does nothing, takes about 24ms.)  This overhead would\n  be incurred by every command that is not pure C.\n\n* Should the scripting language access the C functionality only by\n  calling pure-C executables or by dynamically or statically linking to\n  a binary module interface?  If the former, then the granularity of\n  interactions between \"X\" and C is necessarily coarse, and \"X\" cannot\n  be used to implement anything but the outermost layer of\n  functionality.  If the latter, then the way would be clear to\n  implement much more of git in \"X\" (and lua would also be worth\n  considering).\n\n* Learning curve for developers: how difficult is it for a typical git\n  developer to become conversant with \"X\", considering both (1) how\n  likely is it that the typical git developer already knows \"X\" and\n  (2) how straightforward and predictable is the language \"X\"?\n  In this category I think that Python has a huge advantage over\n  Perl, though certainly opinions will differ and Ruby would also be\n  a contender.\n\nPersonally, I regret wasting my time programming pointer arithmetic in\ngit modules that are not performance-critical (and correcting bugs by\nothers in these areas).  And I'm tired of having an idea to improve a\ngit feature only to find that it is implemented in shell, where not even\narrays are available.  I would therefore welcome more friendliness\ntowards a decent scripting language in the git project.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"203796","messageId":"20121125105707.GA25212@thyrsus.com","threadId":"32189","inReplyTo":"50B1F684.5020805@alum.mit.edu","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T10:57:08Z","receivedAt":"2012-11-25T10:57:08Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu>:\n> There is, of course, the awkward issue of how/when to transition to\n> Python 3.x, which is *not* backwards compatible with Python 2.x.  I\n> expect that when the time comes there will be volunteers (myself\n> included) willing to help adapt Python scripts to the new version, but\n> the problem shouldn't be minimized.\n\n2to3 actually does a pretty good job.  It doesn't reduce the\ntransition cost to zero, but I find it does reduce that cost to an\neasily manageable level even on quite large codebases.\n\n> It would be insane to rewrite performance-critical C code in any\n> scripting language, but there is a huge penumbra of code that is not\n> performance critical and that mutates rapidly.\n\nIndeed.  In the git architecture there is a pretty clear dividing line -\nto a first approximation, plumbing should remain C but porcelain should\nprobably not.  (Not that I am advocating forcing such a move - but it would\nbe good to allow it to happen.)\n\nThe 80-20 rule (80% of the execution time is spent in 20% of the code)\nhelps us here.  The *other* 80% of the code can move to a scripting\nlanguage with no significant performance loss.  To find out what needs\nto stay in C, run a profiler!\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203805","messageId":"CAMP44s1oRpm4QkhcbfAuxK8UTZnuSVfNhAQnmUd1xiwhwLEqGw@mail.gmail.com","threadId":"32189","inReplyTo":"20121125095356.GA22279@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-25T11:19:19Z","receivedAt":"2012-11-25T11:19:19Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 10:53 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> If your friends jump off a bridge, would you? Yes, using python has\n>> served them well, but as opposed to what? Other scripting languages? I\n>> don't think so.\n>\n> The competition that Python won was *precisely* against other scripting\n> languages, notably shell and Perl.  Both used to be much more heavily\n> used in system scripting than they are now.\n\nAgainst shell and perl yes, not against the rest.\n\n>> What if my extension only supports python 2.7? Or what if my extension\n>> wants to support 2.0?\n>\n> I propose that if 2.6 can't support it, then that should be considered\n> grounds to reject it.\n\nSeems sensible, but I don't know what \"rejection\" would actually mean.\nMy \"extensions\" are on the way to the contrib area. Is the contrib\narea supposed to have different rules? I don't know.\n\nEither way, making a script work on python 2.6 is probably easier than\ntrying to \"reject\" it.\n\n>> Yes, they should _if_ they know what version they need. In my\n>> extensions I really have no idea.\n>\n> Then you shouldn't submit those extensions to be folded into core git.\n\nToo late.\n\n>> > 3) We should be unconditionally be encouraging extensions to move\n>> > from shell and Perl to Python.  This would be a clear net gain is\n>> > portability and maintainability.\n>>\n>> NO! It's up to the developer to choose what language to use,\n>\n> I agree.  You seem to be raising a lot of straw men.  'Encouragement'\n> does not equate to beating anyone who makes an unpopular choice over\n> the head.\n\nI don't see what this means in practical terms. People are going to\nwrite code in whatever language they want to write code in. How\nexactly are \"we\" going to \"encourage\" them not to do that is not\nentirely clear to me.\n\nI don't think there's such a thing as \"git leadership\" that would be\nable to take these policy decisions, and if there was one, I don't\nthink the evidence presented would be enough to weigh in either way.\n\n> I am also not suggesting that the whole git core ought to be hoicked\n> over to Python.  I was thinking mainly about extension subcommands,\n> not what's in libgit now.\n\nSubcommands are also probably more efficient in c. And lets remember\nthat most people use git through the *official* subcommands.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203806","messageId":"CACsJy8BgOpWdxgCfwBwZ=abAEDr+sbj3hnmKY2EYCFeBPRUT7w@mail.gmail.com","threadId":"32189","inReplyTo":"50B1F684.5020805@alum.mit.edu","subject":"Re: Python extension commands in git - request for policy change","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-11-25T11:25:45Z","receivedAt":"2012-11-25T11:25:45Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Nov 25, 2012 at 5:44 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On the contrary, there is *constant* traffic on the mailing list about\n> incompatibilities between different shell implementations (sh, dash,\n> bash, etc), not to mention those in other utilities (sed, grep, etc)\n> that one is forced to work with in shell scripts.  Compatibility is a\n> *huge* pain when developing shell code for git.  The fact that users\n> typically don't encounter such problems is due to the hard work of POSIX\n> lawyers on the mailing list correcting the compatibility errors of\n> mortal programmers.\n\nI think we still are in the process of moving away from shell-based\ncommands (not the shell interface), just not enough man power to do it\nfast. The only shell-based command with active development is\ngit-submodule. So most shell PITA is in the test suite.\n\n> The most important issues to consider when imagining a future with a\n> hybrid of code in C and some scripting language \"X\" are:\n>\n> * Portability: is \"X\" available on all platforms targeted by git, in\n>   usable and mutually-compatible versions?\n>\n> * Startup time: Is the time to start the \"X\" interpreter prohibitive?\n>   (On my computer, \"python -c pass\", which starts the Python\n>   interpreter and does nothing, takes about 24ms.)  This overhead would\n>   be incurred by every command that is not pure C.\n>\n> * Should the scripting language access the C functionality only by\n>   calling pure-C executables or by dynamically or statically linking to\n>   a binary module interface?  If the former, then the granularity of\n>   interactions between \"X\" and C is necessarily coarse, and \"X\" cannot\n>   be used to implement anything but the outermost layer of\n>   functionality.  If the latter, then the way would be clear to\n>   implement much more of git in \"X\" (and lua would also be worth\n>   considering).\n>\n> * Learning curve for developers: how difficult is it for a typical git\n>   developer to become conversant with \"X\", considering both (1) how\n>   likely is it that the typical git developer already knows \"X\" and\n>   (2) how straightforward and predictable is the language \"X\"?\n>   In this category I think that Python has a huge advantage over\n>   Perl, though certainly opinions will differ and Ruby would also be\n>   a contender.\n\n* We might also need an embedded language variant, like Jeff's lua\nexperiment. I'd be nice if \"X\" can also take this role.\n-- \nDuy\n"},{"id":"203807","messageId":"CAMP44s0WYiV3hTE7u28_Wd59FkGfu3o_psS0gocpnibzN4--Fg@mail.gmail.com","threadId":"32189","inReplyTo":"50B1F684.5020805@alum.mit.edu","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-25T11:40:24Z","receivedAt":"2012-11-25T11:40:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 11/25/2012 09:53 AM, Felipe Contreras wrote:\n>> On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n>>> 1) In 2012, we can specify a \"floor\" Python version of 2.6 (shipped in\n>>> 2008) and be pretty much guaranteed it will be anywhere we want to\n>>> deploy except Windows.  Windows will remain a problem because Python\n>>> isn't part of the stock install, but that's an equal or worse problem\n>>> for shell and Perl - and at least the Python project ships a binary\n>>> installer for Windows.\n>>\n>> What if my extension only supports python 2.7? Or what if my extension\n>> wants to support 2.0?\n>\n> There would obviously have to be a policy like \"all Python code in core\n> git must run on any Python interpreter with 2.6 <= version < 3.0\", just\n> as there are policies about what C and shell features are allowed.  If\n> you happen to want to support earlier versions of Python, I don't see\n> why anybody would stop you as long as your code also runs in the\n> mandated versions.\n\nOf course, but there are experts in C and shell around, not so many\npython experts. So if somebody sneaks in a python program that makes\nuse of features specific to python 2.7, I doubt anybody would notice.\nAnd if they did, I doubt that would be reason enough for rejection,\nsupposing that porting to 2.6 would be difficult enough.\n\nAnyway, I think this is all guesswork.\n\n> Of course Perl will have the same problem if Perl6 ever materializes.\n\nIt *might*, it might not be as severe.\n\n>>> 2) Python extension commands should test the Python version on startup\n>>> and die loudly but gracefully in the rare case that they don't find\n>>> what they need.\n>>\n>> Yes, they should _if_ they know what version they need. In my\n>> extensions I really have no idea.\n>\n> Then simply (with the help of the mailing list) ensure that your\n> extensions run under 2.6 (or whatever the chosen minimum version is) and\n> everything will be OK.  It is not an error to specify 2.6 as the minimum\n> version even though your script happens also to run on older versions :-)\n\nWho would do that? I don't see a lot of people.\n\n>>> 3) We should be unconditionally be encouraging extensions to move\n>>> from shell and Perl to Python.  This would be a clear net gain is\n>>> portability and maintainability.\n>>\n>> NO! It's up to the developer to choose what language to use, and I\n>> find it very chauvinist of you to say \"python is better, so let's all\n>> use python\". So far you have listed a few advantages of python, but\n>> you haven't explained so far what is wrong with shell and perl.\n>\n> Given that some languages are accepted in git-core and others are not,\n> it's already not \"up to the developer to choose what language to use\".\n> At best there is a short list of \"blessed\" languages, and the developer\n> can choose among only those.\n\nThey are not because they haven't been proposed. Things change.\n\n>> In fact, while advancing python you have made clear a problem with\n>> python; the version requirements. So far I have *never* encountered a\n>> problem with git because of my bash version, or my perl version. And\n>> we haven't touched to the python3 mess yet. To me, those are\n>> advantages of shell and perl.\n>\n> On the contrary, there is *constant* traffic on the mailing list about\n> incompatibilities between different shell implementations (sh, dash,\n> bash, etc), not to mention those in other utilities (sed, grep, etc)\n> that one is forced to work with in shell scripts.  Compatibility is a\n> *huge* pain when developing shell code for git.  The fact that users\n> typically don't encounter such problems is due to the hard work of POSIX\n> lawyers on the mailing list correcting the compatibility errors of\n> mortal programmers.\n\n*Theoretical* incompatibilities on probably obscure systems. *I* have\nnever seen such compatibility issues *in practice*.\n\n>> Actually, I don't care if 'git foo' is written in perl, or shell, or\n>> c; as long as it *works*. And I would hate it if 'git rebase' ever\n>> told me that I need a newer version of python, or worst; that I don't\n>> have python in my system (Arch Linux ships 'python2', not 'python').\n>\n> The configure script would locate the correct interpreter and the build\n> would adjust the scripts' shebang lines, just as things are tweaked\n> within Perl scripts at build time.\n\nArch Linux doesn't use no configure script. And what if I'm building\ngit myself (I've hit the issue multiple times)? Perl might have\nsimilar issues on other systems, but not on Arch Linux; /usr/bin/perl\nis there.\n\n>>> 4) We should be encouraging C code to move to Python, too.  There's\n>>> little gain in portability on this path because modern C has cleaned\n>>> up its act a lot, but the drop in expected bug loads would be well\n>>> worth the porting effort.  Segfaults are not your friend, and the x2 to\n>>> x5 drop in line count would do very good things for long-term\n>>> maintainability.\n>>\n>> Definitely NO! I really really doubt git in python would be able to\n>> achieve the same performance as git in c, but to show me wrong, it\n>> wouldn't be very difficult to run a few measurements with python\n>> dulwich *if* we are even to begin considering this point.\n>>\n>> And are segmentation faults really that different from python's\n>> exceptions? Not to the user.\n>\n> There is one huge difference: it C it is all too easy to write code that\n> leads to a security hole due to buffer overflows and other memory\n> management errors.  Code written in a scripting language are largely\n> immune to such problems (except of course for any such bugs in the\n> interpreter itself, but the testing of the interpreter is shared across\n> many projects and users).\n>\n> It would be insane to rewrite performance-critical C code in any\n> scripting language, but there is a huge penumbra of code that is not\n> performance critical and that mutates rapidly.  Such code is much easier\n> to write and maintain in a sane scripting language if the portability\n> issues can be mastered.\n\nI think git developers are perfectly able to write such a code.\n\n> The most important issues to consider when imagining a future with a\n> hybrid of code in C and some scripting language \"X\" are:\n>\n> * Portability: is \"X\" available on all platforms targeted by git, in\n>   usable and mutually-compatible versions?\n>\n> * Startup time: Is the time to start the \"X\" interpreter prohibitive?\n>   (On my computer, \"python -c pass\", which starts the Python\n>   interpreter and does nothing, takes about 24ms.)  This overhead would\n>   be incurred by every command that is not pure C.\n\nAgree.\n\n> * Should the scripting language access the C functionality only by\n>   calling pure-C executables or by dynamically or statically linking to\n>   a binary module interface?  If the former, then the granularity of\n>   interactions between \"X\" and C is necessarily coarse, and \"X\" cannot\n>   be used to implement anything but the outermost layer of\n>   functionality.  If the latter, then the way would be clear to\n>   implement much more of git in \"X\" (and lua would also be worth\n>   considering).\n\nI think this is very far fetched at the moment. Proposals such as\nlibgit2 are moving things forward, but we are pretty far from a goal\nlike that.\n\n> * Learning curve for developers: how difficult is it for a typical git\n>   developer to become conversant with \"X\", considering both (1) how\n>   likely is it that the typical git developer already knows \"X\" and\n>   (2) how straightforward and predictable is the language \"X\"?\n>   In this category I think that Python has a huge advantage over\n>   Perl, though certainly opinions will differ and Ruby would also be\n>   a contender.\n\nRight, but I have the feeling that most git developers are perfectly\nfamiliar with C already. In order to move to something else, and all\nthe necessary burden of learning, or becoming more familiar with X, a\ncompelling argument must be put forward, and I haven't seen such an\nargument.\n\n> Personally, I regret wasting my time programming pointer arithmetic in\n> git modules that are not performance-critical (and correcting bugs by\n> others in these areas).  And I'm tired of having an idea to improve a\n> git feature only to find that it is implemented in shell, where not even\n> arrays are available.  I would therefore welcome more friendliness\n> towards a decent scripting language in the git project.\n\nMe too, if ruby was one of them.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203808","messageId":"CAMP44s1cG=5D9DppHmB9CpgkgdEzM72KhQ1Q-kWrrDo8ST+r_g@mail.gmail.com","threadId":"32189","inReplyTo":"20121125095429.GB22279@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-25T11:48:31Z","receivedAt":"2012-11-25T11:48:31Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 10:54 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n>> > Nguyen Thai Ngoc Duy <pclouds@gmail.com>:\n>> >> These may apply to other languages as well. Where do we draw a line?\n>> >\n>> > I'm in favor of the general policy of avoiding scripting languages\n>> > other than the top three most widely deployed.  At the moment that\n>> > means shell, Python, Perl; on present trends, in a few years Perl\n>> > (dropping in popularity) might be passed by Ruby on the way up.\n>>\n>> Top three according to whom?\n>\n> According to the LOC counts in git's codebase.\n\nNot according to ohloh:\n\n1) shell 33%\n2) tcl 9%\n3) perl 9.7%\n\n4) python 1.8%\n\nAnd this is a non-sequitur; you are proposing to change git policies\nbased on numbers that are a direct result of git's policies?\n\nhttps://www.ohloh.net/p/git/analyses/latest/languages_summary\n\n-- \nFelipe Contreras\n"},{"id":"203809","messageId":"alpine.DEB.2.02.1211250344360.32333@nftneq.ynat.uz","threadId":"32189","inReplyTo":"20121125105707.GA25212@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2012-11-25T11:51:12Z","receivedAt":"2012-11-25T11:51:12Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 25 Nov 2012, Eric S. Raymond wrote:\n\n> Michael Haggerty <mhagger@alum.mit.edu>:\n>> There is, of course, the awkward issue of how/when to transition to\n>> Python 3.x, which is *not* backwards compatible with Python 2.x.  I\n>> expect that when the time comes there will be volunteers (myself\n>> included) willing to help adapt Python scripts to the new version, but\n>> the problem shouldn't be minimized.\n>\n> 2to3 actually does a pretty good job.  It doesn't reduce the\n> transition cost to zero, but I find it does reduce that cost to an\n> easily manageable level even on quite large codebases.\n>\n>> It would be insane to rewrite performance-critical C code in any\n>> scripting language, but there is a huge penumbra of code that is not\n>> performance critical and that mutates rapidly.\n>\n> Indeed.  In the git architecture there is a pretty clear dividing line -\n> to a first approximation, plumbing should remain C but porcelain should\n> probably not.  (Not that I am advocating forcing such a move - but it would\n> be good to allow it to happen.)\n>\n> The 80-20 rule (80% of the execution time is spent in 20% of the code)\n> helps us here.  The *other* 80% of the code can move to a scripting\n> language with no significant performance loss.  To find out what needs\n> to stay in C, run a profiler!\n\nRemember that old code is tested code. The mere act of re-writing it from \nscratch is likely to introduce new bugs due to 'simplifications' by the person \nre-writing the code.\n\nIf a particular piece of code has a track record of being buggy, this may be \noverwelmed by the fresh start and new attention (plus whatever theoretical \nadvantage any particular language provides), but unless it's suspect, re-writing \nit for the sole reason of changing the language is unlikely to be a win.\n\nIn addition, a good programmer working in a 'bad' language that they are very \nfamiliar with is going to write better code than that same programmer would \nwrite in a 'good' language that they are not familiar with.\n\nI git, the programmers are very familiar with C and Bash, but far less familiar \nwith either Perl or Python (although from what I see, far more familiar with \nPerl than Python)\n\nIf it's something going into contrib, where the core developers are not needing \nto maintain it, the language it's written in matters far less than if it's \nsomething that's going to be in the core. If it's in the core, it needs to be in \na language that the core developers are comforatable with.\n\nYou may think that C and Bash are poor choices, but that is what the community \nis familar with.\n\nYou are far from the first person to say that git should be re-written (or at \nleast large portions of it) in the language-of-the-day, and you won't be the \nlast (even, or especially if it does get re-written in Python ;-)\n\nDavid Lang\n"},{"id":"203810","messageId":"50B20887.5060601@gmail.com","threadId":"32189","inReplyTo":"alpine.DEB.2.02.1211250344360.32333@nftneq.ynat.uz","subject":"Re: Python extension commands in git - request for policy change","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2012-11-25T12:01:11Z","receivedAt":"2012-11-25T12:01:11Z","isPatch":false,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"Hi David.  One minor but important correction ...\n\nOn 11/25/2012 12:51 PM, David Lang wrote:\n>\n> You may think that C and Bash are poor choices, but that is what the\n> community is familar with.\n>\nActually, it is C and POSIX shell -- not merely bash.  Indeed, the shell\ncode in Git is expected to work with the Solaris Korn shell, the BSD\n/bin/sh, the dash shell (which is now the default /bin/sh on Debian and\nUbuntu), etc.\n\n(Oh, and on the python vs. C vs. shell diatribe I'm mostly neutral,\nmostly because I'm no Git developer, and I have no \"cents to throw\").\n\nRegards,\n  Stefano\n"},{"id":"203813","messageId":"CABPQNSY+Tnij4+_uZq3zwmgVjtUGsYpB7miJgf8meUWMCArNMg@mail.gmail.com","threadId":"32189","inReplyTo":"20121125103316.GA24514@thyrsus.com","subject":"Re: Re: Python extension commands in git - request for policy change","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-11-25T15:51:39Z","receivedAt":"2012-11-25T15:51:39Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Sun, Nov 25, 2012 at 11:33 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Pat Thoyts <patthoyts@gmail.com>:\n>> Git for Windows simply ships everything we need to run git - so if a\n>> desirable module requires a version of python, we will add that\n>> version plus any required modules into the installer. We already have\n>> a patch to provide python in the msysgit tree - it would just require\n>> polishing up a little. I'm certain this is no problem for the other\n>> windows port (cygwin) either.\n>\n> Thank you - I think this completely disposes of the \"Windows is a blocker\n> for scripting language X\" argument, with the case X = Python in point.\n\nAs the one who wrote that patch; not at all. That patch is a horrible\nmess, and it is not yet proven that the resulting python executable\nworks any more than a basic hello world.\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203816","messageId":"alpine.DEB.1.00.1211251806390.7256@s15462909.onlinehome-server.info","threadId":"32189","inReplyTo":"20121125051809.GA3670@thyrsus.com","subject":"Re: Re: Python extension commands in git - request for policy change","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2012-11-25T17:21:08Z","receivedAt":"2012-11-25T17:21:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nthank you Duy for thinking of Cc:ing the msysGit mailing list. We indeed\ndo not have a working Python in Git for Windows yet (mainly because I did\nnot review kusma's patch yet thanks to a non-fun-at-all side track).\n\nOn Sun, 25 Nov 2012, Eric S. Raymond wrote:\n\n> Nguyen Thai Ngoc Duy <pclouds@gmail.com>:\n> > These may apply to other languages as well. Where do we draw a line?\n> \n> I'm in favor of the general policy of avoiding scripting languages\n> other than the top three most widely deployed.\n\nIt is one thing to allow users to use the scripting languages of their\nchoice to do their work.\n\nIt is a different thing completely to allow the core of an important piece\nof software like Git to consist of a hodge podge of languages. There are\nso many problems already, both technical and social ones [*1*], that I would\nreally like to caution against letting even more languages creep into the\ncore. It is bad enough already.\n\nCiao,\nDscho\n\nFootnote [*1*]: Technical problems include serious performance issues on\nWindows when using shell/Perl scripting (see the many, many complaints\nabout git-svn just as an example), portability problems (I am thankful\nthat Junio seems to insist at least on POSIX compatibility of shell\nscripts still even if there are very vocal forces trying to get lazy on\nthat front).\n\nAnd do not underestimate the social problems with *requiring* contributors\nto know yet another language well just because you let a core part be\nwritten in that language. There is even a rule of thumb: increase the\nnumber of languages used in your program == halve the number of potential\ncontributors. And if you think that this is theoretical: look at the mails\nwe got about Git GUI being written in Tcl/Tk (hardly a difficult language\nto learn) and losing contributors over it.\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203817","messageId":"20121125173229.GA32394@thyrsus.com","threadId":"32189","inReplyTo":"CAMP44s1oRpm4QkhcbfAuxK8UTZnuSVfNhAQnmUd1xiwhwLEqGw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T17:32:29Z","receivedAt":"2012-11-25T17:32:29Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> Seems sensible, but I don't know what \"rejection\" would actually mean.\n\nWhy is this mysterious?  We reject a patch when we don't choose to merge it.\n\n> My \"extensions\" are on the way to the contrib area. Is the contrib\n> area supposed to have different rules? I don't know.\n\nI don't have a strong opinion about this.  I lean towards looser rules\nfor contrib because, among other things, it's a place for experiments\nand we disclaim responsibility for maintaining it. But requiring 2.6\ncompatibility for Python scripts is not really onerous.\n\n> Too late.\n\nI'd be happy to help you out by auditing them for version dependencies.\n\n> I don't see what this means in practical terms. People are going to\n> write code in whatever language they want to write code in. How\n> exactly are \"we\" going to \"encourage\" them not to do that is not\n> entirely clear to me.\n\nOne way is by having clear guidelines for good practice that *include*\nPython, and tell people exactly what the requirements are.\n\n> Subcommands are also probably more efficient in c. And lets remember\n> that most people use git through the *official* subcommands.\n\nSee my remarks on the 80-20 rule elsewhere in the thread.  Execessive\nworship of \"efficiency\" is a great way to waste effort and pile up\nhidden costs in maintainance problems.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203818","messageId":"20121125173607.GB32394@thyrsus.com","threadId":"32189","inReplyTo":"CAMP44s0WYiV3hTE7u28_Wd59FkGfu3o_psS0gocpnibzN4--Fg@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T17:36:07Z","receivedAt":"2012-11-25T17:36:07Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> Of course, but there are experts in C and shell around, not so many\n> python experts. So if somebody sneaks in a python program that makes\n> use of features specific to python 2.7, I doubt anybody would notice.\n\nI would.\n\n> And if they did, I doubt that would be reason enough for rejection,\n> supposing that porting to 2.6 would be difficult enough.\n\nIn cases like that, backporting is usually pretty easy.  Been there, done that.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203819","messageId":"20121125174425.GC32394@thyrsus.com","threadId":"32189","inReplyTo":"alpine.DEB.2.02.1211250344360.32333@nftneq.ynat.uz","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T17:44:25Z","receivedAt":"2012-11-25T17:44:25Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"David Lang <david@lang.hm>:\n> You may think that C and Bash are poor choices, but that is what the\n> community is familar with.\n\nI don't think C is a \"poor\" choice.  bash, on the other hand...so\nmany dependencies on tool quirks!\n\n> You are far from the first person to say that git should be\n> re-written (or at least large portions of it) in the\n> language-of-the-day, and you won't be the last (even, or especially\n> if it does get re-written in Python ;-)\n\nI think you're overinterpreting.  Trying for One Big Rewrite in language\nX is almost never a good idea and I don't advocate it.  Encouraging people\nto migrate pieces as they feel motivated and resdy is a different matter.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203820","messageId":"20121125175051.GD32394@thyrsus.com","threadId":"32189","inReplyTo":"CAMP44s1cG=5D9DppHmB9CpgkgdEzM72KhQ1Q-kWrrDo8ST+r_g@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T17:50:51Z","receivedAt":"2012-11-25T17:50:51Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> Not according to ohloh:\n> \n> 1) shell 33%\n> 2) tcl 9%\n> 3) perl 9.7%\n> \n> 4) python 1.8%\n\nLook in the Makefile - all that tcl code is buried in gitk.  We're\nvery, very lucky the author did such a good job, because it's a\npotentially serious headache; who can maintain it?\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203822","messageId":"CAMP44s3QNG-sxcZsWmL3RYjXkzOwerj2774t7Abh04A7QR6TCA@mail.gmail.com","threadId":"32189","inReplyTo":"20121125175051.GD32394@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-25T21:22:38Z","receivedAt":"2012-11-25T21:22:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 6:50 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> Not according to ohloh:\n>>\n>> 1) shell 33%\n>> 2) tcl 9%\n>> 3) perl 9.7%\n>>\n>> 4) python 1.8%\n>\n> Look in the Makefile - all that tcl code is buried in gitk.  We're\n> very, very lucky the author did such a good job, because it's a\n> potentially serious headache; who can maintain it?\n\nAnd gitk is an integral part of git. But if you have different\nnumbers, what are they?\n\n-- \nFelipe Contreras\n"},{"id":"203823","messageId":"CAMP44s2fSpL13kDAm9W2ti-MERpKukNzNZ_Yt0oOOWMYOQPr2Q@mail.gmail.com","threadId":"32189","inReplyTo":"20121125173607.GB32394@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-25T21:25:51Z","receivedAt":"2012-11-25T21:25:51Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 6:36 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> Of course, but there are experts in C and shell around, not so many\n>> python experts. So if somebody sneaks in a python program that makes\n>> use of features specific to python 2.7, I doubt anybody would notice.\n>\n> I would.\n\nAnd are you going to be around to spot them? It seems my patches for\ngit-remote-hg slipped by your watch, because it seems they use stuff\nspecific to python 2.7.\n\n>> And if they did, I doubt that would be reason enough for rejection,\n>> supposing that porting to 2.6 would be difficult enough.\n>\n> In cases like that, backporting is usually pretty easy.  Been there, done that.\n\nExactly. Why would you reject something you can fix easily?\n\n-- \nFelipe Contreras\n"},{"id":"203825","messageId":"20121125214139.GA29465@shrek.podlesie.net","threadId":"32189","inReplyTo":"20121125024451.1ADD14065F@snark.thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2012-11-25T21:41:39Z","receivedAt":"2012-11-25T21:41:39Z","isPatch":false,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Sat, Nov 24, 2012 at 09:44:51PM -0500, Eric S. Raymond wrote:\n> \n> We're behind the best-practices curve here.  The major Linux\n> distributions, which have to deal with almost the same set of\n> tradeoffs we do, went to Python for pretty much all glue and\n> administration scripts outside /etc a decade ago, and the decision has\n> served them well.\n> \n> That, among other things, means up-to-date versions of Python are\n> ubiquitous unless we're looking at Windows - in which case Perl and\n> shell actually become much bigger portability problems.  Mac OS X \n> has kept up to date, too; Lion shipped 2.7.1 and that was a major\n> release back at this point.\n> \n\nWhat about embedded systems? git is also useful there. C and shell is\neverywhere, python is not. Adding additional dependency if it's not\nreally needed it's not a good idea.\n\nAlso not everyone uses up-to-date systems and sometimes you just\ncare about some critical parts and do not touch everything else and\nthere is probably quote large number of systems with python < 2.6.\nAnd even when you keep your system up-to-date, there are some GNU/Linux\ndistros that are still supported, but does not provide recent python - for\ninstance PLD Ac, which I still use on some systems and will use\nuntil the hardware dies, provides only python 2.4.6 (by the way,\nimportant packages like git are of course quite recent there - 1.7.11.1).\n\nKrzysiek\n"},{"id":"203826","messageId":"CAMP44s2ft7vvaGqHUa2CytpAsX8vOF3YQo24PLPsD6y1Dk3GZQ@mail.gmail.com","threadId":"32189","inReplyTo":"20121125173229.GA32394@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-25T21:43:08Z","receivedAt":"2012-11-25T21:43:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 6:32 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> Seems sensible, but I don't know what \"rejection\" would actually mean.\n>\n> Why is this mysterious?  We reject a patch when we don't choose to merge it.\n\nWhy would you reject it? If, according to you, it's very simple to fix\nthe portability, then presumably it would take you less time to fix\nit, than to reject it (and everything that implies).\n\n>> Too late.\n>\n> I'd be happy to help you out by auditing them for version dependencies.\n\nBe my guest:\nhttp://git.kernel.org/?p=git/git.git;a=tree;f=contrib/remote-helpers;h=adfdcc164e634c74024c8f69bb0cdb9f3b4a9f18;hb=7b4a70c62f3a83fbd8b44bf712141754a5f64205\n\nSome patches might be missing, so:\nhttps://github.com/felipec/git/tree/fc/remote/hg\n\n>> I don't see what this means in practical terms. People are going to\n>> write code in whatever language they want to write code in. How\n>> exactly are \"we\" going to \"encourage\" them not to do that is not\n>> entirely clear to me.\n>\n> One way is by having clear guidelines for good practice that *include*\n> Python, and tell people exactly what the requirements are.\n\nThe key word being guideline, which is different from a strict rule.\n\n>> Subcommands are also probably more efficient in c. And lets remember\n>> that most people use git through the *official* subcommands.\n>\n> See my remarks on the 80-20 rule elsewhere in the thread.  Execessive\n> worship of \"efficiency\" is a great way to waste effort and pile up\n> hidden costs in maintainance problems.\n\nAccording to the results of the last survey, our users do care about\nperformance, so I don't think there's anything excessive about it. Are\nthere any hidden costs in maintenance problems? I don't think so.\n\nThe people that like to improve the performance of git, would keep\ndoing so, and the people that want to use fancy scripts to do fancy\nstuff, will keep doing so. It just happens that the former have\nactually managed to do it, and go all the way into the mainline.\n\nIt would be great if we had a finished libgit2 with all the essential\nstuff, and good bindings for python (and other languages), and it\nwould be great if python really was this touted language, that is easy\nto read, and would make things more maintainable. Unfortunately,\nthat's not the case.\n\nI could write an endless list of what things in the python language\ndon't make any sense, and how in ruby, for example, they do.\nFortunately, I don't have to.\n\nGit does have problems, but they have nothing to do with maintenance,\nor C; they have to do with the user interface, and the documentation\n(again, according to our users (and me)). So, I don't see why worry\nabout moving code from C to python when barely any code in git is\npython, specially if it doesn't fix any real issue.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203827","messageId":"20121125215635.GA6937@thyrsus.com","threadId":"32189","inReplyTo":"CAMP44s3QNG-sxcZsWmL3RYjXkzOwerj2774t7Abh04A7QR6TCA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T21:56:35Z","receivedAt":"2012-11-25T21:56:35Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> And gitk is an integral part of git. But if you have different\n> numbers, what are they?\n\nI looked at the Makefile.  I saw that there are shell variables that collect\nC commands, shell command, Perl commands, and Python commands.  There are no\ncollections of other commands.  That makes them the top languages in the\nuniverse we are concerned about\n\nPlease don't waste further time on quibbling.  We all know that gitk is\nan uncomfortable special case and that the project would be far better\noff, maintainability-wise, if it were successfully ported to one if these\nother languages.  Trying to catch me out by triumphantly pointing at gitk \nis...juvenile.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203828","messageId":"20121125221126.GB6937@thyrsus.com","threadId":"32189","inReplyTo":"CAMP44s2fSpL13kDAm9W2ti-MERpKukNzNZ_Yt0oOOWMYOQPr2Q@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T22:11:26Z","receivedAt":"2012-11-25T22:11:26Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> And are you going to be around to spot them? It seems my patches for\n> git-remote-hg slipped by your watch, because it seems they use stuff\n> specific to python 2.7.\n\nThe dev group hasn't decided (in whatever way it decides these\nthings) to require 2.6 yet.  When and if it does, I will volunteer my\nservices as a Python expert to audit the in-tree Python code for 2.6\nconformance and assist the developers in backporting if required.\nI will also make myself available to audit future submissions.  \n\nI think you know who I am. Junio and the other senior devs certainly\nknow where to find me. I've been making promises like this, and\n*keeping* them, for decades.  Please stop wasting our time with\npetulant display.\n\n> Exactly. Why would you reject something you can fix easily?\n\nI wouldn't.  The point of a policy like this is not to kick incoming\nsubmissions over the horizon as though that were some sort of\naccomplishment, it's to let submitters know what is required of\nthem so they can code up to a standard that supports maintainability.\nIt would be no different than any of our other portability requirements.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203829","messageId":"20121125224443.GC6937@thyrsus.com","threadId":"32189","inReplyTo":"CAMP44s2ft7vvaGqHUa2CytpAsX8vOF3YQo24PLPsD6y1Dk3GZQ@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T22:44:44Z","receivedAt":"2012-11-25T22:44:44Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> > I'd be happy to help you out by auditing them for version dependencies.\n> \n> Be my guest:\n> http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/remote-helpers;h=adfdcc164e634c74024c8f69bb0cdb9f3b4a9f18;hb=7b4a70c62f3a83fbd8b44bf712141754a5f64205\n> \n> Some patches might be missing, so:\n> https://github.com/felipec/git/tree/fc/remote/hg\n\nOK, here's what I look for:  use of argparse, use of unittest, use\nof Collections.counters, use or ordered dictionaries, use of set literals,\nuse of multiple context managers in one \"with\", use of memoryview, use of\nthe comma format specifier.  I'm not worried about the changes in repr()\nfor floating point; I'd be astonished if they mattered in code like this.\nLikewise for PyCapsule and importlib.\n\nI don't see obvious problems in that code.  Looks pretty vanilla, actually;\nthe latest version-related blocker I can see is the import of json,\nwhich would have been a problem before 2.5.\n\nYou wrote the code.  Do you *know* of 2.7-specific constructions in\nthere that I've missed?  If you do, and think of this as a way to\ncatch me in a mistake and dance triumphantly, you lose - our goal\nshould be to cooperate to improve the auditing process, not score\nsilly points.\n\n> > One way is by having clear guidelines for good practice that *include*\n> > Python, and tell people exactly what the requirements are.\n> \n> The key word being guideline, which is different from a strict rule.\n\nAgreed. It's a matter for the dev group to decide when we need rules\nand when we need guidelines.  I think we need a rule about Python version\nconformance that protects older systems, but other things can be guidelines.\n\n> According to the results of the last survey, our users do care about\n> performance, so I don't think there's anything excessive about it. Are\n> there any hidden costs in maintenance problems? I don't think so.\n\nThen you're either pretending or very naive. Three decades of\nexperience as a C programmer tells me that C code at any volume is a\n*serious* maintainance problem relative to almost any language with\nGC.  Prudent architects confine it is much as possible.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203830","messageId":"20121125224728.GD6937@thyrsus.com","threadId":"32189","inReplyTo":"20121125214139.GA29465@shrek.podlesie.net","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-25T22:47:28Z","receivedAt":"2012-11-25T22:47:28Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Krzysztof Mazur <krzysiek@podlesie.net>:\n> What about embedded systems? git is also useful there. C and shell is\n> everywhere, python is not.\n\nSupposing this is true (and I question it with regard to shell) if you\ntell me how you live without gitk and the Perl pieces I'll play that\nright back at you as your answer.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"203854","messageId":"CAMK1S_g2jpa+VqnuzhNaBNkC5bJHwbEy1iP-=sG29FFKmjTjpw@mail.gmail.com","threadId":"32189","inReplyTo":"20121125224728.GD6937@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-11-26T05:10:00Z","receivedAt":"2012-11-26T05:10:00Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Krzysztof Mazur <krzysiek@podlesie.net>:\n>> What about embedded systems? git is also useful there. C and shell is\n>> everywhere, python is not.\n>\n> Supposing this is true (and I question it with regard to shell) if you\n> tell me how you live without gitk and the Perl pieces I'll play that\n> right back at you as your answer.\n\ngitk is unlikely to be used on an embedded system, the perl pieces more so.\n\nI have never understood why people complain about readability in perl.\n Just because it uses the ascii charset a bit more?  You expect a\nmathematician or indeed any scientist to use special symbols to mean\nspecial things, why not programmers?\n\nPerhaps people should be forced to use COBOL for a few years (like I\ndid, a long while ago) to appreciate brevity.\n"},{"id":"203861","messageId":"20121126083202.GA29437@shrek.podlesie.net","threadId":"32189","inReplyTo":"CAMK1S_g2jpa+VqnuzhNaBNkC5bJHwbEy1iP-=sG29FFKmjTjpw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Krzysztof Mazur","fromEmail":"krzysiek@podlesie.net","sentAt":"2012-11-26T08:32:03Z","receivedAt":"2012-11-26T08:32:03Z","isPatch":false,"sender":{"key":"krzysiek@podlesie.net","avatar":null},"body":"On Mon, Nov 26, 2012 at 10:40:00AM +0530, Sitaram Chamarty wrote:\n> On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> > Krzysztof Mazur <krzysiek@podlesie.net>:\n> >> What about embedded systems? git is also useful there. C and shell is\n> >> everywhere, python is not.\n> >\n> > Supposing this is true (and I question it with regard to shell) if you\n> > tell me how you live without gitk and the Perl pieces I'll play that\n> > right back at you as your answer.\n> \n> gitk is unlikely to be used on an embedded system, the perl pieces more so.\n\nCurrently even perl is used only for few very high level commands that\nare not really needed there. I think that python is ok for pieces\nthat use perl now, but I think that it shouldn't be used for\nbasic porcelain commands. I also don't think that we should prefer\npython over other languages and especially I don't think that some\nexisting code should be rewritten to python.\n\nEven if python is really better, I think that the natural migration is\nmuch better.\n\n> \n> I have never understood why people complain about readability in perl.\n>  Just because it uses the ascii charset a bit more?  You expect a\n> mathematician or indeed any scientist to use special symbols to mean\n> special things, why not programmers?\n> \n\nBecause some perl programmers really create write-only code, but the\nmaintainer can just reject that code. It's not the language that\ncreate non-readable code, but the programmer. I think that the perl\ncode in git is readable, at least is parts I've seen.\n\nKrzysiek\n"},{"id":"203865","messageId":"50B34D08.8000208@op5.se","threadId":"32189","inReplyTo":"20121125224443.GC6937@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-11-26T11:05:44Z","receivedAt":"2012-11-26T11:05:44Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 11/25/2012 11:44 PM, Eric S. Raymond wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> According to the results of the last survey, our users do care about\n>> performance, so I don't think there's anything excessive about it. Are\n>> there any hidden costs in maintenance problems? I don't think so.\n> \n> Then you're either pretending or very naive. Three decades of\n> experience as a C programmer tells me that C code at any volume is a\n> *serious* maintainance problem relative to almost any language with\n> GC.  Prudent architects confine it is much as possible.\n> \n\nPrudent architects also avoid rewrites as much as possible, since it's\ninevitable that bugs will be introduced that have been fixed in the\n\"official\" version.\n\nPersonally, I think if you'd left your suggestion on \"It would be great\nto have guidelines for python scripts. I propose 2.6 as the minimum\nrequired python verison\" and left it at that, there would have been\nvery little disagreement. The suggestion that things should be rewritten\nin python for some spurious long-term savings seems mostly designed to\nrefuel everyone's favourite flamethrower, and you know as well as I do\nthat it just won't happen unless there's at least a chance of some\nsubstantial technical benefits from doing so.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"203876","messageId":"CAMP44s2FcrjDhNzond=Rzmn5QOBnZbQC1d73ZmKNeyCRvJNvyA@mail.gmail.com","threadId":"32189","inReplyTo":"20121125215635.GA6937@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-26T13:11:57Z","receivedAt":"2012-11-26T13:11:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> And gitk is an integral part of git. But if you have different\n>> numbers, what are they?\n>\n> I looked at the Makefile.  I saw that there are shell variables that collect\n> C commands, shell command, Perl commands, and Python commands.  There are no\n> collections of other commands.\n\nI suppose you are talking about BUILT_INS, and SCRIPT_FOO, but tcl\nscripts don't need no SCRIPT_FOO stuff, because they don't need to be\nregenerated, in fact, I don't think the shell scripts need to be\nregenerated, but that's not important, what is important is this:\n\nall::\nifndef NO_TCLTK\n\t$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all\n\t$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all\nendif\n\nWhy are you ignoring that?\n\n> That makes them the top languages in the universe we are concerned about\n\nAccording to whom?\n\nI find it very curious how you are arguing for a change in the status\nquo to move more towards python, and the basis you are using for\nchoosing python, and not ruby, or other scripting language is\nprecisely the status quo. However, the only scripts using python are\nthese:\n\nSCRIPT_PYTHON += git-remote-testgit.py\nSCRIPT_PYTHON += git-p4.py\n\nI already re-wrote git-remote-testgit in bash, and it's dubious\nwhether or not git-remote-testpy (the new name for this old test) will\nfulfill any service. Than means 43% of the current python code is\ngone.\n\nAnd what happens if I rewrite git-p4 in ruby? Would you then argue\nthat ruby is the way to go because 1% of the *current* code-base uses\nit?\n\nInterestingly, according to Wikipedia git is written in: C, Bourne\nShell, Tcl, Perl. That seems to be the case.\n\n> Please don't waste further time on quibbling.  We all know that gitk is\n> an uncomfortable special case and that the project would be far better\n> off, maintainability-wise, if it were successfully ported to one if these\n> other languages.\n\nAs I said, gitk is integral to the git experience. Of course you are\nfree to disagree, but according to the last user survey 57% of the\nresponders used some kind of graphical tool (e.g. gitk, tig). How many\nuse gitk, and how many use something else, we don't really know, but\nwhat we know is that gitk is distributed *by default*.\n\nNobody is arguing that gitk should not be distributed by default, just\nlike nobody is arguing that git-p4 shouldn't, but we *know* very few\npeople use git-p4 (1% according to the survey), and we can reasonably\nassume that many more use gitk.\n\nYou cannot have your cake and eat it at the same time. If you use the\namount of code as a measure, then you have to agree that Tcl/Tk is a\nway bigger language than python in the mainline git world. If not,\nthen by all means, show us the numbers. But you can't say \"the\nimportant languages are A, B, and D, C doesn't count because I don't\nlike it, and E doesn't count either because we should draw the line at\nthree\", that seems awfully convenient to push your agenda.\n\nAnd I don't agree that the project would be better off with something\nelse, if it was, somebody would have proposed an alternative by now,\nbut there aren't any. I have tried gitg, and giggle, and I have even\ncontributed to them, but they are just not as good and useful as plain\nold gitk, I always keep coming back.\n\ngitk:\n * is blazing fast to start\n * doesn't have a lot of dependencies: just tcl/tk\n * works on Windows without a major fuzz\n * is actively maintained\n * shows a proper graph (unlike gitg or giggle)\n\nNow, show me an alternative that fulfills all these points. And I'm\npretty sure you won't find one, because if you did, it would have been\nalready proposed for mainline git... there isn't any. And if you did,\nwe would start with oh, but it's GTK+, or it's Qt, and how do you make\nit work on Windows. No, gitk is just fine, and works great.\n\nTcl/Tk might not be your cup of tea, and indeed it's rather unmodern,\nbut that only tells you how an awful job the modern toolkits have done\nwith regards to portability and flexibility.\n\nYou were arguing for portability, well, Tcl/Tk works on all platforms,\nhere, have a look, there's no other tool that fulfills this:\n\nhttp://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces\n\n> Trying to catch me out by triumphantly pointing at gitk is...juvenile.\n\nIsn't that what you are doing by triumphantly pointing at git-p4?\n\nSorry, if you want to cut the line for the languages that git should\nuse right now at three, then python is out. Maybe in a couple of\nyears. Maybe. But I doubt it.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203877","messageId":"CAMP44s3KqCs2N0iiExyN8PGGXe72SROAuJX7xWxW1GnnpVivtQ@mail.gmail.com","threadId":"32189","inReplyTo":"20121125221126.GB6937@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-26T13:17:15Z","receivedAt":"2012-11-26T13:17:15Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 11:11 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> And are you going to be around to spot them? It seems my patches for\n>> git-remote-hg slipped by your watch, because it seems they use stuff\n>> specific to python 2.7.\n>\n> The dev group hasn't decided (in whatever way it decides these\n> things) to require 2.6 yet.  When and if it does, I will volunteer my\n> services as a Python expert to audit the in-tree Python code for 2.6\n> conformance and assist the developers in backporting if required.\n> I will also make myself available to audit future submissions.\n\nWhat dev group?\n\n> I think you know who I am. Junio and the other senior devs certainly\n> know where to find me. I've been making promises like this, and\n> *keeping* them, for decades.  Please stop wasting our time with\n> petulant display.\n\nAll right, you don't wand feedback, fine.\n\nIf you need me I'll be rewriting python code to ruby.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203971","messageId":"CAJDDKr4cr3VXqx=CXgXSQrVTSjE=f=55HZns-xfNziJOXb3Vsw@mail.gmail.com","threadId":"32189","inReplyTo":"CAMP44s2FcrjDhNzond=Rzmn5QOBnZbQC1d73ZmKNeyCRvJNvyA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2012-11-27T07:54:34Z","receivedAt":"2012-11-27T07:54:34Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> And I don't agree that the project would be better off with something\n> else, if it was, somebody would have proposed an alternative by now,\n> but there aren't any. I have tried gitg, and giggle, and I have even\n> contributed to them, but they are just not as good and useful as plain\n> old gitk, I always keep coming back.\n>\n> gitk:\n>  * is blazing fast to start\n>  * doesn't have a lot of dependencies: just tcl/tk\n>  * works on Windows without a major fuzz\n>  * is actively maintained\n>  * shows a proper graph (unlike gitg or giggle)\n>\n> Now, show me an alternative that fulfills all these points. And I'm\n> pretty sure you won't find one, because if you did, it would have been\n> already proposed for mainline git... there isn't any. And if you did,\n> we would start with oh, but it's GTK+, or it's Qt, and how do you make\n> it work on Windows. No, gitk is just fine, and works great.\n>\n> Tcl/Tk might not be your cup of tea, and indeed it's rather unmodern,\n> but that only tells you how an awful job the modern toolkits have done\n> with regards to portability and flexibility.\n>\n> You were arguing for portability, well, Tcl/Tk works on all platforms,\n> here, have a look, there's no other tool that fulfills this:\n>\n> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces\n\n*cough* git-cola *cough*\n\nit runs everywhere.  Yes, windows too. It's written in python.\nIt's been actively maintained since 2007.\n\nIt's \"modern\" and has features that don't exist anywhere else.\n\nIt even has tests.  It even comes with a building full of willing\nguinea-pigs^Wtesters that let me know right away when\nanything goes wrong.\n\nIt uses Qt but that's really the whole point of Qt -> cross-platform.\n(not sure how that wiki page ended up saying Gnome/GTK?)\n\nThe DAG aka git-dag (in its master branch, about to be released)\nis nicer looking then gitk IMO.  gitk still has some features\nthat are better too--there's no silver bullet, but the delta\nis pretty small.\n\nThe only point this doesn't fulfill is dependency-free-ness.\nWith that requirement the answer can *only* be tcl/tk.\nSo saying, \"go look for one you won't find it\" is really\na tautology.  It's not even an entertaining one.\n\nhttp://xkcd.com/703/\n\nWhen the requirement is, \"what is the best user experience\npossible\", then you use a mature GUI library.  These are different\nrequirements and probably different use cases.  For the gitk use\ncase, gitk is the perfect tool.\n\nAnyways, just sayin', you make it sound like this stuff doesn't\nexist, but it does.  I've never proposed it for mainline\ngit because I'm very aware of the dependency requirements.\n\nBut, if git \"recommended\" it I would very much appreciate the\nextra eyes and contributions.  Being in mainline git could\npossibly help with that.  A submodule under contrib/\nwould be an interesting experiment.\n\nIn any case, I think documenting the python standards\n(even if within contrib/ only) is a good thing.\n\nWe'd be increasing the overall portability by documenting\nwhat we support and sticking to it, just\nlike what is done for shell scripts and perl versions.\nEric is helping make that happen, let's not  throw\nout the baby with the bathwater.  FWIW, I would also make\nmy python expertise available.\n\nThis thread has gotten into meta-meta territory --\nit's discussing code that has not yet even been written,\nand going off on all sorts of tangents.\n\nLet's stay on target.  I think bringing up python\nas an extension language would help in a these key areas:\n\n- There are a few python modules floating around that\n  are similar to the ruby grit library.  Having an official\n  python module would be good.\n\n- Commands on the edges of the git experience (GUIs,\n  import/export/etc) can benefit from python.  git-p4\n  is one example.  git-weave is another.\n\nAre there any arguments against it for these use cases?\n\n\nBTW, Felipe, if you're going to be rewriting python code to ruby,\nplease, pretty please rewrite that darn GUI ;-)\n\nYou can call it \"git-new-cola: project kansas\"\n\nhttp://en.wikipedia.org/wiki/New_Coke\n\nI expect a patch by the morning ;-p\n\nI kid, of course, but if you do pull it off I WILL buy you a soda-pop!\n-- \nDavid\n"},{"id":"203979","messageId":"CAMP44s1gpAPpK2yHmLOroj+7Y7OZaXTj9SGqC0cxgFgO-3Ap8w@mail.gmail.com","threadId":"32189","inReplyTo":"CAJDDKr4cr3VXqx=CXgXSQrVTSjE=f=55HZns-xfNziJOXb3Vsw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-27T08:43:29Z","receivedAt":"2012-11-27T08:43:29Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Nov 27, 2012 at 8:54 AM, David Aguilar <davvid@gmail.com> wrote:\n> On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n\n>> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces\n>\n> *cough* git-cola *cough*\n>\n> it runs everywhere.  Yes, windows too. It's written in python.\n> It's been actively maintained since 2007.\n\n% sudo pacman -S git-cola\nerror: target not found: git-cola\n\nhttp://aur.archlinux.org/packages/gi/git-cola/git-cola.tar.gz\n% makepkg\n\n==> Missing Dependencies:\n  -> python2-pyqt>=4.3\n==> Checking buildtime dependencies...\n==> Missing Dependencies:\n  -> asciidoc\n  -> docbook-xsl\n  -> rsync\n  -> xmlto\n  -> python2-sphinx>=1.1.3\n\nSorry, no.\n\nI'm not sure if you have been following, but msysgit doesn't seem to\nhave good support for python, let alone Qt. In my view the fact that\nit uses python is not a good thing.\n\n> It's \"modern\" and has features that don't exist anywhere else.\n>\n> It even has tests.  It even comes with a building full of willing\n> guinea-pigs^Wtesters that let me know right away when\n> anything goes wrong.\n>\n> It uses Qt but that's really the whole point of Qt -> cross-platform.\n> (not sure how that wiki page ended up saying Gnome/GTK?)\n\nYes, Qt is cross-platform *in theory*, but have you used any Qt\napplication in Windows? I haven't.\n\n> The DAG aka git-dag (in its master branch, about to be released)\n> is nicer looking then gitk IMO.  gitk still has some features\n> that are better too--there's no silver bullet, but the delta\n> is pretty small.\n\nIf you mean this one:\nhttp://1.1.1.5/bmi/git-cola.github.com/images/dag.png\n\nThen I wholeheartedly disagree.\n\n> The only point this doesn't fulfill is dependency-free-ness.\n> With that requirement the answer can *only* be tcl/tk.\n> So saying, \"go look for one you won't find it\" is really\n> a tautology.  It's not even an entertaining one.\n\nThat's the whole point; there is nothing else. If there was something\nelse, there would be something else. But there isn't.\n\n> When the requirement is, \"what is the best user experience\n> possible\", then you use a mature GUI library.  These are different\n> requirements and probably different use cases.\n\nBut those are not the requirements.\n\n> Anyways, just sayin', you make it sound like this stuff doesn't\n> exist, but it does.  I've never proposed it for mainline\n> git because I'm very aware of the dependency requirements.\n\nA lot of stuff exists. And people use a lot of those. But they don't\nfulfill the requirements that I think gitk does perfectly.\n\n> But, if git \"recommended\" it I would very much appreciate the\n> extra eyes and contributions.  Being in mainline git could\n> possibly help with that.  A submodule under contrib/\n> would be an interesting experiment.\n\nIt might be, if somebody actually tried to submit the code. But I\nhonestly doubt so.\n\n> In any case, I think documenting the python standards\n> (even if within contrib/ only) is a good thing.\n>\n> We'd be increasing the overall portability by documenting\n> what we support and sticking to it, just\n> like what is done for shell scripts and perl versions.\n> Eric is helping make that happen, let's not  throw\n> out the baby with the bathwater.  FWIW, I would also make\n> my python expertise available.\n\nNobody has argued that there shouldn't be guidelines for python code.\nWhat I have objected is to 'strict rules'.\n\n> This thread has gotten into meta-meta territory --\n> it's discussing code that has not yet even been written,\n> and going off on all sorts of tangents.\n\nThat is the point; why should we change the policy for code that\nhasn't been written yet? That's not how things evolve in git as far as\nI have seen.\n\n> BTW, Felipe, if you're going to be rewriting python code to ruby,\n> please, pretty please rewrite that darn GUI ;-)\n\nI would need to write a widget toolkit first =/ I think I'll pass. gitk is fine.\n\nCheers.\n\n-- \nFelipe Contreras\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203983","messageId":"CAMK1S_j_F6PQ73zUP9QaDBR6FVd7fMY==D9vxwpwVwRUbfkB4Q@mail.gmail.com","threadId":"32189","inReplyTo":"CAJDDKr4cr3VXqx=CXgXSQrVTSjE=f=55HZns-xfNziJOXb3Vsw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-11-27T09:17:13Z","receivedAt":"2012-11-27T09:17:13Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <davvid@gmail.com> wrote:\n\n> *cough* git-cola *cough*\n>\n> it runs everywhere.  Yes, windows too. It's written in python.\n> It's been actively maintained since 2007.\n>\n> It's \"modern\" and has features that don't exist anywhere else.\n>\n> It even has tests.  It even comes with a building full of willing\n> guinea-pigs^Wtesters that let me know right away when\n> anything goes wrong.\n>\n> It uses Qt but that's really the whole point of Qt -> cross-platform.\n> (not sure how that wiki page ended up saying Gnome/GTK?)\n>\n> The DAG aka git-dag (in its master branch, about to be released)\n> is nicer looking then gitk IMO.  gitk still has some features\n> that are better too--there's no silver bullet, but the delta\n> is pretty small.\n\nGitk does a lot of things that people don't realise, since they're not\nreally documented and you have to scrounge around on the UI.  The\nthing is, it's just about the most awesome tool for code archeology I\nhave seen.\n\nI realise (from looking at the doc page) that git-cola helps you do\nall sorts of things, but those are all things I am happier doing at\nthe command line.\n\nGitk does precisely those things which *require* a GUI, where the\namount of information presented overwhelms a text interface.  The\ndisplay is concisely designed to give you the maximum information at a\nminimum space use.  For example, a little black square when a commit\nhas a note attached.  Even hovering over the arrow-heads, on complex\ntrees where the line gets broken, does something meaningful.\n\nif I had to pin it down, the feature I use most often is \"Show origin\nof this line\".  Other features I use often are\n  - review a commit file by file (f and b keys, also spacebar and 'd')\n  - search by SHA1 (4 digits appear to be enough, regardless of how\nbig your repo is),\n  - search for commits changing path/dir (while still showing all the\ncommits; i.e., this is not 'git-dag -- README.txt' but within gitk you\nsearch up and down for commits touching README.txt\n  - and navigating the commit tree looking for stuff\n\nhttp://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to\ndocument some of the stuff I have found and use.\n\nOne final point: the DAG on the right wastes enormous amounts of\nspace.  Purely subjectively, it is almost jarring on the senses.  (If\nyou reduce it, it becomes unreadable).\n\nWith all due respect, git-cola/dag isn't anywhere near what gitk does,\nat least for people who are not afraid of the command line and only\nneed the GUI to visualise a truly complex tree.\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203984","messageId":"CAJDDKr7r5iP_LpXAT9Xz35GOfbDuDxSAKUvx=4dxa2LE_GLgrA@mail.gmail.com","threadId":"32189","inReplyTo":"CAMK1S_j_F6PQ73zUP9QaDBR6FVd7fMY==D9vxwpwVwRUbfkB4Q@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2012-11-27T10:51:04Z","receivedAt":"2012-11-27T10:51:04Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:\n> On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <davvid@gmail.com> wrote:\n>\n>> *cough* git-cola *cough*\n>>\n>> it runs everywhere.  Yes, windows too. It's written in python.\n>> It's been actively maintained since 2007.\n>>\n>> It's \"modern\" and has features that don't exist anywhere else.\n>>\n>> It even has tests.  It even comes with a building full of willing\n>> guinea-pigs^Wtesters that let me know right away when\n>> anything goes wrong.\n>>\n>> It uses Qt but that's really the whole point of Qt -> cross-platform.\n>> (not sure how that wiki page ended up saying Gnome/GTK?)\n>>\n>> The DAG aka git-dag (in its master branch, about to be released)\n>> is nicer looking then gitk IMO.  gitk still has some features\n>> that are better too--there's no silver bullet, but the delta\n>> is pretty small.\n>\n> Gitk does a lot of things that people don't realise, since they're not\n> really documented and you have to scrounge around on the UI.  The\n> thing is, it's just about the most awesome tool for code archeology I\n> have seen.\n>\n> I realise (from looking at the doc page) that git-cola helps you do\n> all sorts of things, but those are all things I am happier doing at\n> the command line.\n\nDitto.  There's actually a few small things I use it for,\nmainly for teasing apart commits.  These days you can use git-gui\nfor that, but in the old days it was the only way to interactively\nselect individual lines and stage/unstage/revert them, etc.\nI don't think we can line-by-line revert in git-gui yet, though.\n\nSome other small things that I use: ctrl-g, type something\nfor grep, hit enter twice and I'm in my editor on that\n(or any other selected) line.  'spacebar' does xdg-open,\nand 'enter' launches the editor in the status widget;\nsmall things.  I, too, do most stuff on the command line.\n\nThe grep thing is a good example.  You have tons of output,\nyou see the one line that you care about, and you want to jump\nthere.  Clicking on that line and hitting enter is the minimal\neffort to do that.  You don't have to click because we also\nhave keyboard navigation.  I have a feeling that there's probably\nsomething I'm missing, though.. another way of working (emacs?)\nthat would render all of this custom GUI stuff pointless.\n\nWhat I learned about users:\n\nThe commit editor is the #1 thing that got my coworkers finally\nwriting better commit messages. It forces the subject/description\nseparation and shows yellow, red when the subject gets too long.\nIt also auto-wraps.  IMO it makes sense for git-gui to do\nthe same these days.\n\n> Gitk does precisely those things which *require* a GUI, where the\n> amount of information presented overwhelms a text interface.  The\n> display is concisely designed to give you the maximum information at a\n> minimum space use.  For example, a little black square when a commit\n> has a note attached.  Even hovering over the arrow-heads, on complex\n> trees where the line gets broken, does something meaningful.\n>\n> if I had to pin it down, the feature I use most often is \"Show origin\n> of this line\".  Other features I use often are\n>   - review a commit file by file (f and b keys, also spacebar and 'd')\n>   - search by SHA1 (4 digits appear to be enough, regardless of how\n> big your repo is),\n>   - search for commits changing path/dir (while still showing all the\n> commits; i.e., this is not 'git-dag -- README.txt' but within gitk you\n> search up and down for commits touching README.txt\n>   - and navigating the commit tree looking for stuff\n>\n> http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to\n> document some of the stuff I have found and use.\n\nWow, this is awesome.\n\n> One final point: the DAG on the right wastes enormous amounts of\n> space.  Purely subjectively, it is almost jarring on the senses.  (If\n> you reduce it, it becomes unreadable).\n>\n> With all due respect, git-cola/dag isn't anywhere near what gitk does,\n> at least for people who are not afraid of the command line and only\n> need the GUI to visualise a truly complex tree.\n\nThis is really great feedback.\ncc:ing Guillaume since he had similar ideas.\n\nthx,\n-- \nDavid\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"203990","messageId":"20121127143510.GA15831@google.com","threadId":"32189","inReplyTo":"CAMP44s0WYiV3hTE7u28_Wd59FkGfu3o_psS0gocpnibzN4--Fg@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Magnus Bäck","fromEmail":"baeck@google.com","sentAt":"2012-11-27T14:35:11Z","receivedAt":"2012-11-27T14:35:11Z","isPatch":false,"sender":{"key":"baeck@google.com","avatar":null},"body":"On Sunday, November 25, 2012 at 06:40 EST,\n     Felipe Contreras <felipe.contreras@gmail.com> wrote:\n\n> On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty\n> <mhagger@alum.mit.edu> wrote:\n\n[...]\n\n> > On the contrary, there is *constant* traffic on the mailing list\n> > about incompatibilities between different shell implementations (sh,\n> > dash, bash, etc), not to mention those in other utilities (sed,\n> > grep, etc) that one is forced to work with in shell scripts.\n> > Compatibility is a *huge* pain when developing shell code for git.\n> > The fact that users typically don't encounter such problems is due\n> > to the hard work of POSIX lawyers on the mailing list correcting the\n> > compatibility errors of mortal programmers.\n>\n> *Theoretical* incompatibilities on probably obscure systems. *I* have\n> never seen such compatibility issues *in practice*.\n\nWhile \"constant traffic\" probably overstates the issue, these are not\ntheoretical problems. I recall at least three cases in the last year\nor so where Git has seen breakage with Solaris or Mac OS X because\nof sed or tr incompatibilities, and I don't even read this list that\nthoroughly.\n\n[...]\n\n-- \nMagnus Bäck\nbaeck@google.com\n"},{"id":"203991","messageId":"alpine.DEB.1.00.1211271632030.7256@s15462909.onlinehome-server.info","threadId":"32189","inReplyTo":"CAJDDKr4cr3VXqx=CXgXSQrVTSjE=f=55HZns-xfNziJOXb3Vsw@mail.gmail.com","subject":"Re: Re: Python extension commands in git - request for policy change","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2012-11-27T15:33:35Z","receivedAt":"2012-11-27T15:33:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi David,\n\nOn Mon, 26 Nov 2012, David Aguilar wrote:\n\n> *cough* git-cola *cough*\n\nIf you had a couple of free cycles to help us get Python/Qt compiled in\nmsysGit, I will be happy to make a Git for Windows package including\ngit-cola.\n\nCiao,\nDscho\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"204013","messageId":"20121127183530.GB11845@thyrsus.com","threadId":"32189","inReplyTo":"20121127143510.GA15831@google.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-27T18:35:31Z","receivedAt":"2012-11-27T18:35:31Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Magnus Bäck <baeck@google.com>:\n> While \"constant traffic\" probably overstates the issue, these are not\n> theoretical problems. I recall at least three cases in the last year\n> or so where Git has seen breakage with Solaris or Mac OS X because\n> of sed or tr incompatibilities, and I don't even read this list that\n> thoroughly.\n\nThis is exactly the sort of of pain experience would lead me to\nexpect.  \n\nOK, this is where I assume the full Old Fart position (30-year\nold-school Unix guy, author of \"The Art of Unix Programming\", can\nremember the years before Perl and still has sh idioms in his\nfingertips) and say \"Get with the 21st century, people! Or at least\n1990...\"\n\nAs a general scripting language shell sucks *really badly* compared to\nanything new-school. Performance, portability, you name it, it's a\nmess.  It's not so much the shell interpreters itself that are the\nportabilty problem, but (as Magnus implicitly points out) all those\nuserland dependencies on sed and tr and awk and even variants of\nexpr(!) that get dragged in the second you try to get any actual work\ndone.\n\nCan we cease behaving like we're still pounding keys on 110-baud\nteletypes now?  Some old-school Unix habits have persisted long past\nthe point that they're even remotely sane.  Shell programming at any\nvolume above a few lines of throwaway code is one of them - it's\n*nuts* and we should *stop doing it*.\n\n(Yes, I too still make this mistake occasionally out of ancient reflex.\nBut I know I shouldn't, and I always end up regretting it.)\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204026","messageId":"CAMK1S_g-1oqjXAekXyBy6UBxbo-LHWtG_49YHSVsKJKezcLR_w@mail.gmail.com","threadId":"32189","inReplyTo":"20121127183530.GB11845@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-11-27T21:08:01Z","receivedAt":"2012-11-27T21:08:01Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Wed, Nov 28, 2012 at 12:05 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Magnus Bäck <baeck@google.com>:\n>> While \"constant traffic\" probably overstates the issue, these are not\n>> theoretical problems. I recall at least three cases in the last year\n>> or so where Git has seen breakage with Solaris or Mac OS X because\n>> of sed or tr incompatibilities, and I don't even read this list that\n>> thoroughly.\n>\n> This is exactly the sort of of pain experience would lead me to\n> expect.\n>\n> OK, this is where I assume the full Old Fart position (30-year\n> old-school Unix guy, author of \"The Art of Unix Programming\", can\n> remember the years before Perl and still has sh idioms in his\n> fingertips) and say \"Get with the 21st century, people! Or at least\n> 1990...\"\n>\n> As a general scripting language shell sucks *really badly* compared to\n> anything new-school. Performance, portability, you name it, it's a\n> mess.  It's not so much the shell interpreters itself that are the\n> portabilty problem, but (as Magnus implicitly points out) all those\n> userland dependencies on sed and tr and awk and even variants of\n> expr(!) that get dragged in the second you try to get any actual work\n> done.\n\nNot always.  There are several situations where a shell script that\nmakes good use of grep, cut, etc., is definitely much cleaner and more\nelegant than anything you can do in a \"propah\" programming language.\n\nIf the price of doing that is sticking to a base set of primitives,\nit's a small price to pay, not much different from sticking to python\n2.7 or perl 5.8 or whatever.\n\nShell *is* the universal scripting language, not perl (even though we\nall know it is what God himself used to create the world -- see xkcd\n224 if you don't believe me!), not python, not Ruby.\n\n-- \nsitaram\n"},{"id":"204038","messageId":"2308646.YNvKSAecjO@localhost","threadId":"32189","inReplyTo":"CAJDDKr7r5iP_LpXAT9Xz35GOfbDuDxSAKUvx=4dxa2LE_GLgrA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Guillaume DE BURE","fromEmail":"guillaume.debure@gmail.com","sentAt":"2012-11-27T22:01:28Z","receivedAt":"2012-11-27T22:01:28Z","isPatch":false,"sender":{"key":"guillaume.debure@gmail.com","avatar":null},"body":"Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit :\n> On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty <sitaramc@gmail.com> \nwrote:\n> > On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <davvid@gmail.com> wrote:\n> >> *cough* git-cola *cough*\n> >> \n> >> it runs everywhere.  Yes, windows too. It's written in python.\n> >> It's been actively maintained since 2007.\n> >> \n> >> It's \"modern\" and has features that don't exist anywhere else.\n> >> \n> >> It even has tests.  It even comes with a building full of willing\n> >> guinea-pigs^Wtesters that let me know right away when\n> >> anything goes wrong.\n> >> \n> >> It uses Qt but that's really the whole point of Qt -> cross-platform.\n> >> (not sure how that wiki page ended up saying Gnome/GTK?)\n> >> \n> >> The DAG aka git-dag (in its master branch, about to be released)\n> >> is nicer looking then gitk IMO.  gitk still has some features\n> >> that are better too--there's no silver bullet, but the delta\n> >> is pretty small.\n> > \n> > Gitk does a lot of things that people don't realise, since they're not\n> > really documented and you have to scrounge around on the UI.  The\n> > thing is, it's just about the most awesome tool for code archeology I\n> > have seen.\n> > \n> > I realise (from looking at the doc page) that git-cola helps you do\n> > all sorts of things, but those are all things I am happier doing at\n> > the command line.\n> \n> Ditto.  There's actually a few small things I use it for,\n> mainly for teasing apart commits.  These days you can use git-gui\n> for that, but in the old days it was the only way to interactively\n> select individual lines and stage/unstage/revert them, etc.\n> I don't think we can line-by-line revert in git-gui yet, though.\n> \n> Some other small things that I use: ctrl-g, type something\n> for grep, hit enter twice and I'm in my editor on that\n> (or any other selected) line.  'spacebar' does xdg-open,\n> and 'enter' launches the editor in the status widget;\n> small things.  I, too, do most stuff on the command line.\n> \n> The grep thing is a good example.  You have tons of output,\n> you see the one line that you care about, and you want to jump\n> there.  Clicking on that line and hitting enter is the minimal\n> effort to do that.  You don't have to click because we also\n> have keyboard navigation.  I have a feeling that there's probably\n> something I'm missing, though.. another way of working (emacs?)\n> that would render all of this custom GUI stuff pointless.\n> \n> What I learned about users:\n> \n> The commit editor is the #1 thing that got my coworkers finally\n> writing better commit messages. It forces the subject/description\n> separation and shows yellow, red when the subject gets too long.\n> It also auto-wraps.  IMO it makes sense for git-gui to do\n> the same these days.\n> \n> > Gitk does precisely those things which *require* a GUI, where the\n> > amount of information presented overwhelms a text interface.  The\n> > display is concisely designed to give you the maximum information at a\n> > minimum space use.  For example, a little black square when a commit\n> > has a note attached.  Even hovering over the arrow-heads, on complex\n> > trees where the line gets broken, does something meaningful.\n> > \n> > if I had to pin it down, the feature I use most often is \"Show origin\n> > of this line\".  Other features I use often are\n> > \n> >   - review a commit file by file (f and b keys, also spacebar and 'd')\n> >   - search by SHA1 (4 digits appear to be enough, regardless of how\n> > \n> > big your repo is),\n> > \n> >   - search for commits changing path/dir (while still showing all the\n> > \n> > commits; i.e., this is not 'git-dag -- README.txt' but within gitk you\n> > search up and down for commits touching README.txt\n> > \n> >   - and navigating the commit tree looking for stuff\n> > \n> > http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to\n> > document some of the stuff I have found and use.\n> \n> Wow, this is awesome.\n> \n> > One final point: the DAG on the right wastes enormous amounts of\n> > space.  Purely subjectively, it is almost jarring on the senses.  (If\n> > you reduce it, it becomes unreadable).\n> > \n> > With all due respect, git-cola/dag isn't anywhere near what gitk does,\n> > at least for people who are not afraid of the command line and only\n> > need the GUI to visualise a truly complex tree.\n> \n> This is really great feedback.\n> cc:ing Guillaume since he had similar ideas.\n> \n> thx,\n\nThanks David for cc:ing me. I'm sorry I was quite below the radar lately, had \ntoo much work to get back on the dag. What I would really like for the dag is \nto become as useful as the treeview in git extensions \n(http://code.google.com/p/gitextensions/), where it is the central place for \ncheckout, merge, cherry picks... \n\nMy only complaint with git extensions is that it is poorly integrated on my \nlinux desktop, due to framework choice (let's not start a flame war here, it's \nnot the point). On the other hand, git-cola is quite easy to hack on thanks to \nits python roots, well integrated on all OS thanks to Qt, so I thought it \nwould be great to make it at least on par.\n\nHad an opportunity to rework the visuals on the dag, but not yet its \nfunctionalities... As soon as I'm back on normal life, I'll pickup the subject \nagain :)\n\nCheers,\n\nGuillaume\n\n-- \nSkrooge, a free, Open Source, personal finances software for linux, Mac OS, \nWindows\nhttp://skrooge.org\n"},{"id":"204066","messageId":"CAMP44s10krOPD73dL0Ancie=kussk89jK7V5adR3hw=a73CVWw@mail.gmail.com","threadId":"32189","inReplyTo":"20121127143510.GA15831@google.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T00:10:34Z","receivedAt":"2012-11-28T00:10:34Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Nov 27, 2012 at 3:35 PM, Magnus Bäck <baeck@google.com> wrote:\n> On Sunday, November 25, 2012 at 06:40 EST,\n>      Felipe Contreras <felipe.contreras@gmail.com> wrote:\n>\n>> On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty\n>> <mhagger@alum.mit.edu> wrote:\n>\n> [...]\n>\n>> > On the contrary, there is *constant* traffic on the mailing list\n>> > about incompatibilities between different shell implementations (sh,\n>> > dash, bash, etc), not to mention those in other utilities (sed,\n>> > grep, etc) that one is forced to work with in shell scripts.\n>> > Compatibility is a *huge* pain when developing shell code for git.\n>> > The fact that users typically don't encounter such problems is due\n>> > to the hard work of POSIX lawyers on the mailing list correcting the\n>> > compatibility errors of mortal programmers.\n>>\n>> *Theoretical* incompatibilities on probably obscure systems. *I* have\n>> never seen such compatibility issues *in practice*.\n>\n> While \"constant traffic\" probably overstates the issue, these are not\n> theoretical problems. I recall at least three cases in the last year\n> or so where Git has seen breakage with Solaris or Mac OS X because\n> of sed or tr incompatibilities, and I don't even read this list that\n> thoroughly.\n\nMost of the *constant* traffic is about *theoretical*\nincompatibilities, how much of that are real incompatibilities, it's\nnot known. _Some_ of the traffic is about real incompatibilities,\nsure, but you could count only three cases *in a year*. It's not a\nhuge amount. And then, how man this year?\n\nAlso, I would like references to those incompatibilities.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204068","messageId":"CAMP44s27gdDJGNx-UTe1rdQZFpn3M60L=nMyd69gAFo15VnMAA@mail.gmail.com","threadId":"32189","inReplyTo":"20121127183530.GB11845@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T00:16:17Z","receivedAt":"2012-11-28T00:16:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Nov 27, 2012 at 7:35 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n\n> As a general scripting language shell sucks *really badly* compared to\n> anything new-school. Performance, portability, you name it, it's a\n> mess.  It's not so much the shell interpreters itself that are the\n> portabilty problem, but (as Magnus implicitly points out) all those\n> userland dependencies on sed and tr and awk and even variants of\n> expr(!) that get dragged in the second you try to get any actual work\n> done.\n\nSomehow it has worked perfectly fine for us.\n\nAlso, you are ignoring all the advantages that shell has and python does not.\n\n> Can we cease behaving like we're still pounding keys on 110-baud\n> teletypes now?  Some old-school Unix habits have persisted long past\n> the point that they're even remotely sane.  Shell programming at any\n> volume above a few lines of throwaway code is one of them - it's\n> *nuts* and we should *stop doing it*.\n\nYes, let's all switch to ruby! Nah, everybody is still using Unix and\nshells, they work. If they didn't, we wouldn't be having this\nconversation.\n\nWhat is the big problem? Somebody said we hit a few issues per year?\nI've already hit more than that writing code for python just the last\nmonth.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204076","messageId":"20121128005128.GB23224@sigill.intra.peff.net","threadId":"32189","inReplyTo":"CAMP44s10krOPD73dL0Ancie=kussk89jK7V5adR3hw=a73CVWw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-28T00:51:28Z","receivedAt":"2012-11-28T00:51:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:\n\n> > While \"constant traffic\" probably overstates the issue, these are not\n> > theoretical problems. I recall at least three cases in the last year\n> > or so where Git has seen breakage with Solaris or Mac OS X because\n> > of sed or tr incompatibilities, and I don't even read this list that\n> > thoroughly.\n> \n> Most of the *constant* traffic is about *theoretical*\n> incompatibilities, how much of that are real incompatibilities, it's\n> not known. _Some_ of the traffic is about real incompatibilities,\n> sure, but you could count only three cases *in a year*. It's not a\n> huge amount. And then, how man this year?\n> \n> Also, I would like references to those incompatibilities.\n\nTry:\n\n  git log --grep='portab' -- '*.sh'\n\nNot all of the hits are shell portability fixes, but most of them are,\nand they are all in response to real, reported issues. The usual\nculprits are Solaris, BSD (including OS X), and the occasional GNUism.\nAnd that is only the ones that we fixed in response to bug reports for\ncommits in the wild. Many more have been caught in review before needing\na separate patch (grepping the list archive for 'portable' and '\\.sh'\nyields 1800 messages).\n\nSo dealing with shell portability is definitely something we do, and it\nis a minor pain.\n\nBut like you, I think we have been getting along reasonably well with\nshell scripts (and where it is not powerful enough, writing C). No\nsolution is going to be free of portability issues (whether because of\ndiffering versions, because the tool is uncommon on certain platforms,\nor whatever). And because git-core's official API is shell-executable\ncommands, any other language you write ends up looking a lot like shell\nanyway.\n\nIf people are really hankering to write sub-commands of git in python\n(or whatever), I would suggest checking out libgit2 which has a nice set\nof python bindings (and ruby bindings, and C# bindings, and so on). It\ndoesn't have feature parity with git-core yet, but they have been making\na lot of progress.\n\n-Peff\n"},{"id":"204085","messageId":"CAMP44s0FiNRbFHbTtZJiWLDRQmy0VZ_FNGxE40eZrXwCFJ5P7A@mail.gmail.com","threadId":"32189","inReplyTo":"20121128005128.GB23224@sigill.intra.peff.net","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T01:22:09Z","receivedAt":"2012-11-28T01:22:09Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Nov 28, 2012 at 1:51 AM, Jeff King <peff@peff.net> wrote:\n> On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:\n>\n>> > While \"constant traffic\" probably overstates the issue, these are not\n>> > theoretical problems. I recall at least three cases in the last year\n>> > or so where Git has seen breakage with Solaris or Mac OS X because\n>> > of sed or tr incompatibilities, and I don't even read this list that\n>> > thoroughly.\n>>\n>> Most of the *constant* traffic is about *theoretical*\n>> incompatibilities, how much of that are real incompatibilities, it's\n>> not known. _Some_ of the traffic is about real incompatibilities,\n>> sure, but you could count only three cases *in a year*. It's not a\n>> huge amount. And then, how man this year?\n>>\n>> Also, I would like references to those incompatibilities.\n>\n> Try:\n>\n>   git log --grep='portab' -- '*.sh'\n\n% git log --oneline --grep='portab' --since='2 years ago' --no-merges -- '*.sh'\n6eafa6d submodules: don't stumble over symbolic links when cloning recursively\n\nSomebody mentioned 'portable', but no problem was hit.\n\n2718781 t9400: fix gnuism in grep\n\nIt's a test, and nobody was hit by any problem.\n\n0dbe659 t5704: fix nonportable sed/grep usages\n\nApparently there was an issue, but this is a test.\n\n93d5e0c t7810: avoid unportable use of \"echo\"\n\nA problem, but in tests.\n\n482ce70 tests: avoid nonportable {foo,bar} glob\n\nAgain, tests.\n\n77e5726 t0050: fix printf format strings for portability\n\nTests.\n\n\nSo, this search didn't throw a single issue that affected users in two\nyears. Moving git sub-commands to python wouldn't change a thing.\nMaybe shell wasn't the right language for the test system, but I don't\nsee anybody proposing it to be changed.\n\n> Not all of the hits are shell portability fixes, but most of them are,\n> and they are all in response to real, reported issues. The usual\n> culprits are Solaris, BSD (including OS X), and the occasional GNUism.\n> And that is only the ones that we fixed in response to bug reports for\n> commits in the wild. Many more have been caught in review before needing\n> a separate patch (grepping the list archive for 'portable' and '\\.sh'\n> yields 1800 messages).\n>\n> So dealing with shell portability is definitely something we do, and it\n> is a minor pain.\n\nFirst you have to separate the issues with the test system, because\nthat's not going to be changed. And then you have to separate the\n*potential* issues and the *real* ones. You can spend all your time\ndoing \"shell portability\", but does that mean that you actually have a\nproblem? Maybe if you hadn't done anything, nobody would have noticed\nthere was a problem.\n\nSure, you will argue that we don't see the *real* issues, because they\nwere fixed preemptively, but the fact of the matter is that we will\nnever know. All we know is the reality we can observe, and the reality\nis that we hit very few *real* issues outside the test system (feel\nfree to provide evidence to the contrary).\n\n> But like you, I think we have been getting along reasonably well with\n> shell scripts (and where it is not powerful enough, writing C). No\n> solution is going to be free of portability issues (whether because of\n> differing versions, because the tool is uncommon on certain platforms,\n> or whatever). And because git-core's official API is shell-executable\n> commands, any other language you write ends up looking a lot like shell\n> anyway.\n\nAgreed.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204089","messageId":"20121128013943.GA23776@sigill.intra.peff.net","threadId":"32189","inReplyTo":"CAMP44s0FiNRbFHbTtZJiWLDRQmy0VZ_FNGxE40eZrXwCFJ5P7A@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-28T01:39:43Z","receivedAt":"2012-11-28T01:39:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 28, 2012 at 02:22:09AM +0100, Felipe Contreras wrote:\n\n> Sure, you will argue that we don't see the *real* issues, because they\n> were fixed preemptively, but the fact of the matter is that we will\n> never know. All we know is the reality we can observe, and the reality\n> is that we hit very few *real* issues outside the test system (feel\n> free to provide evidence to the contrary).\n\nI think reports of breakage in the test scripts are relevant, because\nthey are indicative that people _do_ run platforms that care about these\nissues, and if we were to write a lot of shell scripts, we would run\nacross them more frequently. But the fact of the matter is that we don't\nwrite a lot of non-test shell scripts these days, which is part of the\nreason limiting your search to the last 2 years did not turn up many\nfixes outside the tests.\n\nThere was a big push in 2006 and 2007 to port some of the hairier\nscripts to C. Try:\n\n  git log --no-renames --diff-filter=D \\\n          --diff-filter=D --format='%ad %s' --date=short \\\n          -- 'git-*.sh'\n\nA lot of it was motivated by portability and decent performance for\ncommon commands under Windows.\n\nAnyway, there is not much point in debating the exact level of pain that\nshell portability causes us. Even if you accept that there is some, it\nis clearly not a major problem for the project.\n\n-Peff\n"},{"id":"204098","messageId":"CAMP44s1jzUWm8BKxJR29RNWTWnxReExTeDTAKhk3mF3WJYNE0w@mail.gmail.com","threadId":"32189","inReplyTo":"20121128013943.GA23776@sigill.intra.peff.net","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T02:06:09Z","receivedAt":"2012-11-28T02:06:09Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Nov 28, 2012 at 2:39 AM, Jeff King <peff@peff.net> wrote:\n> On Wed, Nov 28, 2012 at 02:22:09AM +0100, Felipe Contreras wrote:\n>\n>> Sure, you will argue that we don't see the *real* issues, because they\n>> were fixed preemptively, but the fact of the matter is that we will\n>> never know. All we know is the reality we can observe, and the reality\n>> is that we hit very few *real* issues outside the test system (feel\n>> free to provide evidence to the contrary).\n>\n> I think reports of breakage in the test scripts are relevant, because\n> they are indicative that people _do_ run platforms that care about these\n> issues, and if we were to write a lot of shell scripts, we would run\n> across them more frequently. But the fact of the matter is that we don't\n> write a lot of non-test shell scripts these days, which is part of the\n> reason limiting your search to the last 2 years did not turn up many\n> fixes outside the tests.\n\nIf we were to write a lot of shell scripts, and we were to apply the\nsame standards as we do with the tests, which most likely wouldn't be\nthe case; end-user scripts are way more important, specially\nporcelain.\n\n> There was a big push in 2006 and 2007 to port some of the hairier\n> scripts to C. Try:\n>\n>   git log --no-renames --diff-filter=D \\\n>           --diff-filter=D --format='%ad %s' --date=short \\\n>           -- 'git-*.sh'\n>\n> A lot of it was motivated by portability and decent performance for\n> common commands under Windows.\n\nGood stuff indeed. I look forward to the day all main git porcelain\ncommands are written in C (git-rebase I'm looking at you), there are\nnot many left:\n\ngit-am\ngit-bisect\ngit-citool\ngit-gui\ngit-pull\ngit-rebase\ngit-stash\ngit-submodule\n\n> Anyway, there is not much point in debating the exact level of pain that\n> shell portability causes us. Even if you accept that there is some, it\n> is clearly not a major problem for the project.\n\nIndeed.\n\n-- \nFelipe Contreras\n"},{"id":"204099","messageId":"CAMP44s0UZ2yTKLkp51p9zqO4Quv9_WGO07P20eYeQesgXHxn3Q@mail.gmail.com","threadId":"32189","inReplyTo":"20121125215635.GA6937@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T02:09:12Z","receivedAt":"2012-11-28T02:09:12Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> And gitk is an integral part of git. But if you have different\n>> numbers, what are they?\n\n> Please don't waste further time on quibbling.  We all know that gitk is\n> an uncomfortable special case and that the project would be far better\n> off, maintainability-wise, if it were successfully ported to one if these\n> other languages.  Trying to catch me out by triumphantly pointing at gitk\n> is...juvenile.\n\nAnother bit of information I just realized, 'man git' lists gitk as a\n'Main porcelain command' as high level as any git command can get.\n\n-- \nFelipe Contreras\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"204133","messageId":"50B59C48.5000100@workspacewhiz.com","threadId":"32189","inReplyTo":"50B1F684.5020805@alum.mit.edu","subject":"Re: Python extension commands in git - request for policy change","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2012-11-28T05:08:24Z","receivedAt":"2012-11-28T05:08:24Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"----- Original Message -----\nFrom: Michael Haggerty\nDate: 11/25/2012 3:44 AM\n> * Startup time: Is the time to start the \"X\" interpreter prohibitive?\n>    (On my computer, \"python -c pass\", which starts the Python\n>    interpreter and does nothing, takes about 24ms.)  This overhead would\n>    be incurred by every command that is not pure C.\nFWIW, on Windows 7 running on a Core i7 1.6GHz quad core processor, a \ncold run of \"python -c pass\" after a reboot results in 0.74 seconds.  \nThe second run takes 0.13 seconds.\n\nBecause Lua was mentioned in another message of this thread, I'll \nprovide the following:\n\n* A cold run of 'lua5.1 -e \"\"' takes 0.4 seconds.  The second run takes \n0.03 seconds.\n* A cold run of LuaJIT takes the same.\n\n-Josh\n"},{"id":"204163","messageId":"20121128153955.GA26588@google.com","threadId":"32189","inReplyTo":"CAMP44s10krOPD73dL0Ancie=kussk89jK7V5adR3hw=a73CVWw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Magnus Bäck","fromEmail":"baeck@google.com","sentAt":"2012-11-28T15:39:56Z","receivedAt":"2012-11-28T15:39:56Z","isPatch":false,"sender":{"key":"baeck@google.com","avatar":null},"body":"On Tuesday, November 27, 2012 at 19:10 EST,\n     Felipe Contreras <felipe.contreras@gmail.com> wrote:\n\n> On Tue, Nov 27, 2012 at 3:35 PM, Magnus Bäck <baeck@google.com> wrote:\n>\n> > While \"constant traffic\" probably overstates the issue, these are\n> > not theoretical problems. I recall at least three cases in the last\n> > year or so where Git has seen breakage with Solaris or Mac OS X\n> > because of sed or tr incompatibilities, and I don't even read this\n> > list that thoroughly.\n>\n> Most of the *constant* traffic is about *theoretical*\n> incompatibilities, how much of that are real incompatibilities, it's\n> not known. _Some_ of the traffic is about real incompatibilities,\n> sure, but you could count only three cases *in a year*. It's not a\n> huge amount. And then, how man this year?\n>\n> Also, I would like references to those incompatibilities.\n\nI don't remember the details of the Mac OS X problem, but just searching\nthe archives for \"xpg4\" revealed the following Solaris problems since\nApril:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/195010\nhttp://article.gmane.org/gmane.comp.version-control.git/195966\nhttp://article.gmane.org/gmane.comp.version-control.git/207944\n\n-- \nMagnus Bäck\nbaeck@google.com\n"},{"id":"204469","messageId":"CAGK7Mr4HkCkbw-SV-d=JAmQieV0ZQOE7YqR-g7rTWzHGPYqzHA@mail.gmail.com","threadId":"32189","inReplyTo":"CAMP44s27gdDJGNx-UTe1rdQZFpn3M60L=nMyd69gAFo15VnMAA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2012-12-03T21:45:45Z","receivedAt":"2012-12-03T21:45:45Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> Also, you are ignoring all the advantages that shell has and python does not.\n\nOut of curiosity, can you list the advantages? From what I gathered:\n\n- no need to install bash\n- git contributors are more used to bash\n- there's only one \"version\" of bash (no real need to handle different\nversions compared to py26, py27, etc)\n\nAre there any \"language\" advantage or are all the advantages in the\n\"pragmatic\" section?\nI don't really have an opinion on this topic. A \"real language\" seems\nbetter, but bash's pragmaticity seems to outweight the cons,\nespecially the \"contributors want bash\" argument.\n\nThanks,\nPhilippe\n"},{"id":"204490","messageId":"CAMP44s0rcy6OfMPM+8BhQy0DbxRLBHEsraHw0u4oAZzh5euTzg@mail.gmail.com","threadId":"32189","inReplyTo":"CAGK7Mr4HkCkbw-SV-d=JAmQieV0ZQOE7YqR-g7rTWzHGPYqzHA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-12-04T14:19:18Z","receivedAt":"2012-12-04T14:19:18Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Dec 3, 2012 at 3:45 PM, Philippe Vaucher\n<philippe.vaucher@gmail.com> wrote:\n>> Also, you are ignoring all the advantages that shell has and python does not.\n>\n> Out of curiosity, can you list the advantages? From what I gathered:\n>\n> - no need to install bash\n\nUnless you are in Windows or OS X. OS X has a shell, but not bash.\n\n> - git contributors are more used to bash\n\nI don't see this as a big advantage.\n\n> - there's only one \"version\" of bash (no real need to handle different\n> versions compared to py26, py27, etc)\n\nThis one is.\n\nThe language doesn't change much from different versions of bash either way.\n\n- the language is part of POSIX\n\nWhich means you don't need bash, you can use dash, or zsh, or many other shells.\n\n- the language is simple\n\nIt's so simple it's used in shells.\n\n- no need for extensions\n\nAll you need is the shell binary, that's it.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204491","messageId":"1285092455.205649.1354632031815.JavaMail.root@genarts.com","threadId":"32189","inReplyTo":"CAMP44s0rcy6OfMPM+8BhQy0DbxRLBHEsraHw0u4oAZzh5euTzg@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2012-12-04T14:40:31Z","receivedAt":"2012-12-04T14:40:31Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Felipe Contreras\" <felipe.contreras@gmail.com>\n> Sent: Tuesday, December 4, 2012 9:19:18 AM\n> Subject: Re: Python extension commands in git - request for policy change\n> \n> > > Also, you are ignoring all the advantages that shell has and\n> > > python does not.\n> >\n> > Out of curiosity, can you list the advantages? From what I\n> > gathered:\n> >\n> > - no need to install bash\n> \n> Unless you are in Windows or OS X. OS X has a shell, but not bash.\n\n>From http://support.apple.com/kb/TA27005:\n\n\"The default shell (or command-line interface) used in Mac OS X 10.0 through 10.2.8 is tcsh (with 10.3 and 10.4 it's bash). With Mac OS X 10.2 or later, other interactive shells are included, such as bash and zsh.\"\n\nStephen\n"},{"id":"204492","messageId":"CACPiFCK5rg626iHSdb7qhnvoDHJu+xs2Dp3SXqdHq81SXBMJYA@mail.gmail.com","threadId":"32189","inReplyTo":"20121125024451.1ADD14065F@snark.thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2012-12-04T15:51:19Z","receivedAt":"2012-12-04T15:51:19Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Sat, Nov 24, 2012 at 9:44 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> git presently contains one Python extension command, Pete Wycoff's p4\n> importer.  If my git-weave code is merged it will acquire another.\n\nWrite a really compelling tool. Don't argue languages. Make it\nwonderful. The git maintainers, tool maintainers (you!) and overall\ndevelopment community have shown flexibility and smarts in the past.\n\ncheers,\n\n\nm\n--\n martin.langhoff@gmail.com\n martin@laptop.org -- Software Architect - OLPC\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"204670","messageId":"CACh33FrGPhaeNzZ2Tj5OxScecOPN13idw8TwU8Mf6o0KsAOB9A@mail.gmail.com","threadId":"32189","inReplyTo":"CACsJy8BgOpWdxgCfwBwZ=abAEDr+sbj3hnmKY2EYCFeBPRUT7w@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Patrick Donnelly","fromEmail":"batrick@batbytes.com","sentAt":"2012-12-11T05:44:48Z","receivedAt":"2012-12-11T05:44:48Z","isPatch":false,"sender":{"key":"batrick@batbytes.com","avatar":null},"body":"Sorry I'm late to this party...\n\nI'm an Nmap developer that is casually interested in git development.\nI've been lurking for a while and thought I'd post my thoughts on this\nthread.\n\nOn Sun, Nov 25, 2012 at 6:25 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n>> The most important issues to consider when imagining a future with a\n>> hybrid of code in C and some scripting language \"X\" are:\n>>\n>> * Portability: is \"X\" available on all platforms targeted by git, in\n>>   usable and mutually-compatible versions?\n>>\n>> * Startup time: Is the time to start the \"X\" interpreter prohibitive?\n>>   (On my computer, \"python -c pass\", which starts the Python\n>>   interpreter and does nothing, takes about 24ms.)  This overhead would\n>>   be incurred by every command that is not pure C.\n>>\n>> * Should the scripting language access the C functionality only by\n>>   calling pure-C executables or by dynamically or statically linking to\n>>   a binary module interface?  If the former, then the granularity of\n>>   interactions between \"X\" and C is necessarily coarse, and \"X\" cannot\n>>   be used to implement anything but the outermost layer of\n>>   functionality.  If the latter, then the way would be clear to\n>>   implement much more of git in \"X\" (and lua would also be worth\n>>   considering).\n>>\n>> * Learning curve for developers: how difficult is it for a typical git\n>>   developer to become conversant with \"X\", considering both (1) how\n>>   likely is it that the typical git developer already knows \"X\" and\n>>   (2) how straightforward and predictable is the language \"X\"?\n>>   In this category I think that Python has a huge advantage over\n>>   Perl, though certainly opinions will differ and Ruby would also be\n>>   a contender.\n>\n> * We might also need an embedded language variant, like Jeff's lua\n> experiment. I'd be nice if \"X\" can also take this role.\n\nLua has been an incredible success for Nmap [2](and other projects).\nAs an embedded scripting language, it's unrivaled in terms of ease of\nembedding, ease of use for users, and performance. I would strongly\nrecommend the git developers to seriously consider it.\n\nAddressing the points listed above:\n\n>> * Portability: is \"X\" available on all platforms targeted by git, in\n>>   usable and mutually-compatible versions?\n\nLua is written in ANSI C and so compiles basically anywhere (certainly\nanywhere git does).\n\n>> * Startup time: Is the time to start the \"X\" interpreter prohibitive?\n>>   (On my computer, \"python -c pass\", which starts the Python\n>>   interpreter and does nothing, takes about 24ms.)  This overhead would\n>>   be incurred by every command that is not pure C.\n\nAs mentioned elsewhere in this thread by Joshua:\n\n\"Because Lua was mentioned in another message of this thread, I'll\nprovide the following:\n\n* A cold run of 'lua5.1 -e \"\"' takes 0.4 seconds.  The second run\ntakes 0.03 seconds.\n* A cold run of LuaJIT takes the same.\"\n\nThe runtime figures would probably be much lower if git modules (e.g.\npull) were capable of calling other modules without forking, all\nwithin the same Lua environment.\n\n>> * Should the scripting language access the C functionality only by\n>>   calling pure-C executables or by dynamically or statically linking to\n>>   a binary module interface?  If the former, then the granularity of\n>>   interactions between \"X\" and C is necessarily coarse, and \"X\" cannot\n>>   be used to implement anything but the outermost layer of\n>>   functionality.  If the latter, then the way would be clear to\n>>   implement much more of git in \"X\" (and lua would also be worth\n>>   considering).\n\nUsing Lua as a glue between a proper git C API and modules would be\noptimal in my opinion and experience.\n\n>> * Learning curve for developers: how difficult is it for a typical git\n>>   developer to become conversant with \"X\", considering both (1) how\n>>   likely is it that the typical git developer already knows \"X\" and\n>>   (2) how straightforward and predictable is the language \"X\"?\n>>   In this category I think that Python has a huge advantage over\n>>   Perl, though certainly opinions will differ and Ruby would also be\n>>   a contender.\n\nLua is remarkably easy to learn and is engineered so it's approachable\nby novice (or non-) programmers. Still, it offers all the features you\nexpect from a modern scripting language including GC, real lexical\nscoping and closure, tables/arrays, and *coroutines*. While Nmap\noccasionally gets questions about why we didn't use Python, no one\ncomplains about Lua itself.\n\n\nAs for version considerations, Lua changes at a glacial pace compared\nto other popular languages like Python or Ruby. Lua 5.2 was released\nlast year and 5.1 was released 5 years before that [1]. Still, while\nusers (people who bind Lua to applications) are certainly encouraged\nto upgrade Lua, there is no real need to. Binding Lua to an\napplication statically is not a significant cost as it compiles to\nless than 200 KB including base libraries; so, it's simple and cheap\nto remain independent of the system git runs on. It isn't unreasonable\n-- indeed, it is common -- to select one version of Lua and keep it\nfor a significant lifetime of the project.\n\n[I'd be happy to answer any questions concerning Lua and/or scripting\nGit. I'd also be happy to assist in embedding Lua in Git.]\n\n[1] http://www.lua.org/versions.html\n[2] http://nmap.org/book/nse.html\n\n--\n- Patrick Donnelly\n"},{"id":"204708","messageId":"CAMK1S_hy8U0rVY=-u-QCqXjhn-6jwz5ofj_q_mbokVn8CGCMtw@mail.gmail.com","threadId":"32189","inReplyTo":"CACh33FrGPhaeNzZ2Tj5OxScecOPN13idw8TwU8Mf6o0KsAOB9A@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-12-12T00:09:43Z","receivedAt":"2012-12-12T00:09:43Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly <batrick@batbytes.com> wrote:\n> Sorry I'm late to this party...\n>\n> I'm an Nmap developer that is casually interested in git development.\n> I've been lurking for a while and thought I'd post my thoughts on this\n> thread.\n>\n> On Sun, Nov 25, 2012 at 6:25 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n>>> The most important issues to consider when imagining a future with a\n>>> hybrid of code in C and some scripting language \"X\" are:\n>>>\n>>> * Portability: is \"X\" available on all platforms targeted by git, in\n>>>   usable and mutually-compatible versions?\n>>>\n>>> * Startup time: Is the time to start the \"X\" interpreter prohibitive?\n>>>   (On my computer, \"python -c pass\", which starts the Python\n>>>   interpreter and does nothing, takes about 24ms.)  This overhead would\n>>>   be incurred by every command that is not pure C.\n>>>\n>>> * Should the scripting language access the C functionality only by\n>>>   calling pure-C executables or by dynamically or statically linking to\n>>>   a binary module interface?  If the former, then the granularity of\n>>>   interactions between \"X\" and C is necessarily coarse, and \"X\" cannot\n>>>   be used to implement anything but the outermost layer of\n>>>   functionality.  If the latter, then the way would be clear to\n>>>   implement much more of git in \"X\" (and lua would also be worth\n>>>   considering).\n>>>\n>>> * Learning curve for developers: how difficult is it for a typical git\n>>>   developer to become conversant with \"X\", considering both (1) how\n>>>   likely is it that the typical git developer already knows \"X\" and\n>>>   (2) how straightforward and predictable is the language \"X\"?\n>>>   In this category I think that Python has a huge advantage over\n>>>   Perl, though certainly opinions will differ and Ruby would also be\n>>>   a contender.\n>>\n>> * We might also need an embedded language variant, like Jeff's lua\n>> experiment. I'd be nice if \"X\" can also take this role.\n>\n> Lua has been an incredible success for Nmap [2](and other projects).\n> As an embedded scripting language, it's unrivaled in terms of ease of\n> embedding, ease of use for users, and performance. I would strongly\n> recommend the git developers to seriously consider it.\n\n[snipping the rest; all valid points no doubt]\n\nDoes lua have os.putenv() yet?  The inability to even *set* an env var\nbefore calling something else was a killer for me when I last tried\nit.\n\nThat may make it fine as an embedded language (called *by* something\nelse) but it is a bit too \"frugal\" to use as a glue language (calls\nother things).\n"},{"id":"204709","messageId":"CACh33FoL4fi4m9ekFeSuHOTs=cn818=-tRTh+nBwXLnWXKTFWA@mail.gmail.com","threadId":"32189","inReplyTo":"CAMK1S_hy8U0rVY=-u-QCqXjhn-6jwz5ofj_q_mbokVn8CGCMtw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Patrick Donnelly","fromEmail":"batrick@batbytes.com","sentAt":"2012-12-12T00:28:44Z","receivedAt":"2012-12-12T00:28:44Z","isPatch":false,"sender":{"key":"batrick@batbytes.com","avatar":null},"body":"Hi Sitaram,\n\nOn Tue, Dec 11, 2012 at 7:09 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:\n> On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly <batrick@batbytes.com> wrote:\n>> Lua has been an incredible success for Nmap [2](and other projects).\n>> As an embedded scripting language, it's unrivaled in terms of ease of\n>> embedding, ease of use for users, and performance. I would strongly\n>> recommend the git developers to seriously consider it.\n>\n> [snipping the rest; all valid points no doubt]\n>\n> Does lua have os.putenv() yet?  The inability to even *set* an env var\n> before calling something else was a killer for me when I last tried\n> it.\n\nLua is pretty strict about being entirely ANSI C and makes very few\nexceptions (e.g. dlopen). The exceptions that do exist are only in\nbase libraries which can easily be thrown out.\n\n> That may make it fine as an embedded language (called *by* something\n> else) but it is a bit too \"frugal\" to use as a glue language (calls\n> other things).\n\nAs a glue language, this is a feature. The Programming in Lua (written\nby the architect of Lua) preface [1] contains the philosophy of Lua on\nthis issue.\n\nFor cases where you do need access to functions like putenv, it's\ntrivial to either write wrappers for the functions you want to expose\nor to incorporate a library that does it all, e.g. luaposix which\ncontains the majority of POSIX's system calls.\n\n[1] http://www.lua.org/pil/p1.html\n\n--\n- Patrick Donnelly\n"},{"id":"204710","messageId":"1355273635-ner-4863@calvin","threadId":"32189","inReplyTo":"CAMK1S_hy8U0rVY=-u-QCqXjhn-6jwz5ofj_q_mbokVn8CGCMtw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Tomas Carnecky","fromEmail":"tomas.carnecky@gmail.com","sentAt":"2012-12-12T00:53:55Z","receivedAt":"2012-12-12T00:53:55Z","isPatch":false,"sender":{"key":"tomas.carnecky@gmail.com","avatar":null},"body":"On Wed, 12 Dec 2012 05:39:43 +0530, Sitaram Chamarty <sitaramc@gmail.com> wrote:\n> Does lua have os.putenv() yet?  The inability to even *set* an env var\n> before calling something else was a killer for me when I last tried\n> it.\n\nIf it doesn't, it would be trivial to add. It's a one-liner. It's been a while\nsince I used Lua, but it would be something like this:\n\n    void L_putenv(lua_State *L) {\n        putenv(lua_tostring(L, 1));\n    }\n\nand then somewhere during setup:\n\n    lua_register(L, \"putenv\", L_putenv);\n"},{"id":"204711","messageId":"CACsJy8A9h4QJ_iWvQqTtYa4NPH6Q1Gy0NTozbgukC3=ep58mLA@mail.gmail.com","threadId":"32189","inReplyTo":"1355273635-ner-4863@calvin","subject":"Re: Python extension commands in git - request for policy change","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-12-12T01:50:27Z","receivedAt":"2012-12-12T01:50:27Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky\n<tomas.carnecky@gmail.com> wrote:\n> If it doesn't, it would be trivial to add. It's a one-liner. It's been a while\n> since I used Lua, but it would be something like this:\n>\n>     void L_putenv(lua_State *L) {\n>         putenv(lua_tostring(L, 1));\n>     }\n>\n> and then somewhere during setup:\n>\n>     lua_register(L, \"putenv\", L_putenv);\n\nI should have done my homework before asking, but well.. is there any\nway to automate this? If we use lua for writing \"builtin\" commands,\nwe'll need to export a lot of C functions and writing wrappers like\nthis is boring and time consuming. Also, assume I export fn(char*,int)\nto Lua, then I change the prototype to fn(char*, char*), can Lua spot\nall the call sites at compile time (or something) so I can update\nthem?\n-- \nDuy\n"},{"id":"204714","messageId":"1355278979-ner-1662@calvin","threadId":"32189","inReplyTo":"CACsJy8A9h4QJ_iWvQqTtYa4NPH6Q1Gy0NTozbgukC3=ep58mLA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Tomas Carnecky","fromEmail":"tomas.carnecky@gmail.com","sentAt":"2012-12-12T02:22:59Z","receivedAt":"2012-12-12T02:22:59Z","isPatch":false,"sender":{"key":"tomas.carnecky@gmail.com","avatar":null},"body":"On Wed, 12 Dec 2012 08:50:27 +0700, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky\n> <tomas.carnecky@gmail.com> wrote:\n> > If it doesn't, it would be trivial to add. It's a one-liner. It's been a while\n> > since I used Lua, but it would be something like this:\n> >\n> >     void L_putenv(lua_State *L) {\n> >         putenv(lua_tostring(L, 1));\n> >     }\n> >\n> > and then somewhere during setup:\n> >\n> >     lua_register(L, \"putenv\", L_putenv);\n> \n> I should have done my homework before asking, but well.. is there any\n> way to automate this? If we use lua for writing \"builtin\" commands,\n> we'll need to export a lot of C functions and writing wrappers like\n> this is boring and time consuming. Also, assume I export fn(char*,int)\n> to Lua, then I change the prototype to fn(char*, char*), can Lua spot\n> all the call sites at compile time (or something) so I can update\n> them?\n\nA Patrick mentioned in an earlier email, there is luaposix which includes lots\nof these functions [1]. There may be tools which generate these bindings\nautomatically, but I'm not aware of any. Likewise, I'm not aware of any static\nanalyzer which would be required to spot changes in the prototypes (though you\ncould cover some(most?) of it through tests). The last time I seriously used\nLua and its C bindings was many years ago, so I am not the best person to\nanswer these questions.\n\n[1]: http://luaposix.github.com/luaposix/docs/index.html\n"},{"id":"204712","messageId":"CACh33FqTBOMar=V8=aiE2asZ_ri37fAqeghJLqGecYk=qtvBiQ@mail.gmail.com","threadId":"32189","inReplyTo":"CACsJy8A9h4QJ_iWvQqTtYa4NPH6Q1Gy0NTozbgukC3=ep58mLA@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Patrick Donnelly","fromEmail":"batrick@batbytes.com","sentAt":"2012-12-12T02:26:15Z","receivedAt":"2012-12-12T02:26:15Z","isPatch":false,"sender":{"key":"batrick@batbytes.com","avatar":null},"body":"Hi Duy,\n\nOn Tue, Dec 11, 2012 at 8:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky\n> <tomas.carnecky@gmail.com> wrote:\n>> If it doesn't, it would be trivial to add. It's a one-liner. It's been a while\n>> since I used Lua, but it would be something like this:\n>>\n>>     void L_putenv(lua_State *L) {\n>>         putenv(lua_tostring(L, 1));\n>>     }\n>>\n>> and then somewhere during setup:\n>>\n>>     lua_register(L, \"putenv\", L_putenv);\n>\n> I should have done my homework before asking, but well.. is there any\n> way to automate this?\n\nIf you want these basic POSIX functions, use an existing library.\n\nIf you want to automate adding a number of application specific\nfunctions, you can use swig or similar. AFAIK, all languages rely on\nthird party tools like swig to assist in automated binding generation.\nAlthough, automated binding generation is usually used to make it easy\nto export bindings for multiple languages easily. If Lua is going to\nbe used as a \"standard\" module glue language, using swig is really\noverkill.\n\n> If we use lua for writing \"builtin\" commands,\n> we'll need to export a lot of C functions and writing wrappers like\n> this is boring and time consuming. Also, assume I export fn(char*,int)\n> to Lua, then I change the prototype to fn(char*, char*), can Lua spot\n> all the call sites at compile time (or something) so I can update\n> them?\n\nIf the API calls are generic (don't require special handling), you can\nuse some preprocessor magic to save time/space.\n\n--\n- Patrick Donnelly\n"},{"id":"204713","messageId":"20121212033043.GA24937@thyrsus.com","threadId":"32189","inReplyTo":"CAMK1S_hy8U0rVY=-u-QCqXjhn-6jwz5ofj_q_mbokVn8CGCMtw@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-12-12T03:30:43Z","receivedAt":"2012-12-12T03:30:43Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Sitaram Chamarty <sitaramc@gmail.com>:\n> [snipping the rest; all valid points no doubt]\n\nI meant to respond to Patrick's post earlier.\n\nI haven't actually written any code in lua yet, but I've read the book;\nI think I get it.  I've seen the effects of lua integration on another\nlarge project, Battle for Wesnoth.\n\nI'm not, despite conclusions some people here might have jumped to,\nreligiously attached to Python.  So I can say this: I think lua as a\nlanguage is an *excellent* design.  It is clever, economical,\nminimalist, and (other than the one ugly detail of 1-origin indexing)\nshows consistent good taste.\n\nIt might be a good fit for extending git; I wouldn't be very surprised if\nthat worked. However, I do have concerns about the \"Oh, we'll just\nlash together a binding to C\" attitude common among lua programmers; I\nforesee maintainability problems and the possibility of slow death by\nlow-level details as that strategy tries to scale up.\n\nAnd, of course, one problem with calling back into C a lot is that\nyou walk back into C's resource-management issues.\n\nMy sense is that git's use cases are better served by a glue language\nin the Python/Perl/Ruby class rather than an extension langage. But\nmy mind is open on this issue.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204715","messageId":"50C811ED.4000600@workspacewhiz.com","threadId":"32189","inReplyTo":"20121212033043.GA24937@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2012-12-12T05:11:09Z","receivedAt":"2012-12-12T05:11:09Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"----- Original Message -----\nFrom: Eric S. Raymond\nDate: 12/11/2012 8:30 PM\n> It might be a good fit for extending git; I wouldn't be very surprised if\n> that worked. However, I do have concerns about the \"Oh, we'll just\n> lash together a binding to C\" attitude common among lua programmers; I\n> foresee maintainability problems and the possibility of slow death by\n> low-level details as that strategy tries to scale up.\nI don't understand this statement: \"Oh, we'll just lash together a \nbinding to C\" attitude.\n\n??\n> My sense is that git's use cases are better served by a glue language\n> in the Python/Perl/Ruby class rather than an extension langage. But\n> my mind is open on this issue.\nI spend nearly 100% of my Git time on Windows.\n\nSpawning new processes in Windows is dog slow.  Using 'git rebase', \narguably my favorite Git command, is time-waiting torture.  I'm also on \nabout as fast of a Windows machine as money can buy these days.\n\nI have a Git add-on similar to git-media that uses the smudge and clean \nfilters to read/write large binary files into a separate storage \nlocation.  When checking out a workspace, Git shells out to run a filter \nfor each file it needs to write to the workspace.\n\nI can get a maximum of 100 processes per second with this technique, \nresulting in just 100 files being written to disk.  However, I tend to \nsee closer to 60 files written to disk.\n\nSo, I patched Git to allow the smudge/clean filters to load up a DLL \nthat executes a Lua script.  The Lua script properly retrieves+caches a \nfile locally, or it puts the file on a network share.\n\nThe in-process DLL checkout ends up being every bit as fast as when we \nuse Perforce to sync files to our local workspace.  Git, then, can be a \nPerforce replacement for our needs.\n\n(For those who don't know, Perforce handles large workspaces with \nmassive binary files very efficiently.)\n\nAnyway, my preference is to allow scripts to run in-process within Git, \nbecause it is far, far faster on Windows.  I imagine it is faster than \nforking processes on non-Windows machines, too, but I have no statistics \nto back that up.\n\nPython, Perl, or Ruby can be embedded, too, but Lua probably embeds the \neasiest and smallest out of those other 3 languages.\n\nAnd shell scripts tend to be the slowest on Windows due to the excessive \nnumbers of process invocations needed to get anything reasonable done.\n\n-Josh\n"},{"id":"204716","messageId":"50C812E1.4020108@workspacewhiz.com","threadId":"32189","inReplyTo":"CACh33FqTBOMar=V8=aiE2asZ_ri37fAqeghJLqGecYk=qtvBiQ@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2012-12-12T05:15:13Z","receivedAt":"2012-12-12T05:15:13Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"----- Original Message -----\nFrom: Patrick Donnelly\nDate: 12/11/2012 7:26 PM\n>> If we use lua for writing \"builtin\" commands,\n>> we'll need to export a lot of C functions and writing wrappers like\n>> this is boring and time consuming. Also, assume I export fn(char*,int)\n>> to Lua, then I change the prototype to fn(char*, char*), can Lua spot\n>> all the call sites at compile time (or something) so I can update\n>> them?\n> If the API calls are generic (don't require special handling), you can\n> use some preprocessor magic to save time/space.\nSince I mostly use C++, thanks to template metaprogramming, I get to \nregister functions like so:\n\n         void SomeExistingFunction(char* str, int num);\n\nluaState->GetGlobals().RegisterDirect(\"SomeExistingFunction\", \nSomeExistingFunction);\n\nI certainly am not suggesting C++ be used within Git, but in this case, \nC++ has some nice compile-time advantages.\n\n:)\n\n-Josh\n"},{"id":"204718","messageId":"20121212063208.GA18322@sigill.intra.peff.net","threadId":"32189","inReplyTo":"20121212033043.GA24937@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-12-12T06:32:09Z","receivedAt":"2012-12-12T06:32:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 11, 2012 at 10:30:43PM -0500, Eric S. Raymond wrote:\n\n> My sense is that git's use cases are better served by a glue language\n> in the Python/Perl/Ruby class rather than an extension langage. But\n> my mind is open on this issue.\n\nI think there are really two separate use cases to consider:\n\n  1. Providing snippets of script to Git to get Turing-complete behavior\n     for existing Git features. For example, selecting commits during a\n     traversal (e.g., a better \"log --grep\"), formatting output (e.g., a\n     better \"log --format\" or \"for-each-ref --format\").\n\n  2. Writing whole new git commands in a language that is quicker or\n     easier to develop in than C.\n\nI think (1) is a good match for lua. It's light-weight and easy to\nembed, we can map the few bits of information we want for each snippet\ninto the language (e.g., a commit object as a lua table), and the\nlanguage ecosystem is not that important (the user is more interested in\nwriting readable one-liners manipulating data provided by git than they\nare in calling out to third-party modules).\n\nBut for (2), you are going to care a lot more about the language and its\necosystem (because you'll be interacting more with the world outside of\ngit), and about having bindings to lots of different parts of git\n(because you'll want to do more interesting things than just examine a\nfew data structures).  We provide that right now with executable\nplumbing commands. That's convenient for shell scripts, and you can\nbuild bindings for other languages on top (e.g., see perl/Git.pm).\n\nIt's nicely universal, but of course there are some drawbacks: it's slow\n(fork and pipe overhead), and it's sometimes awkward (parsing, quoting,\nno interactivity between caller and plumbing). The other obvious choice\nfor a lingua franca is a linkable C library, with bindings in your\nlanguage of choice.\n\nIt would take a lot of effort to expose git-core's internals in a clean\nway; you'd probably be better off starting from scratch and rewriting\nlarge parts in a friendly library-like manner. Fortunately, there is\nalready a project underway to do so: libgit2.  It does not yet have\nfeature parity with git, but it can do quite a bit.  And there are\nalready ruby and python bindings.\n\n-Peff\n"},{"id":"204719","messageId":"CACh33FrgZhsKp7o9ki6n1AbfRKYYbdLMWuGUGKUqDfH5m0Akng@mail.gmail.com","threadId":"32189","inReplyTo":"20121212063208.GA18322@sigill.intra.peff.net","subject":"Re: Python extension commands in git - request for policy change","fromName":"Patrick Donnelly","fromEmail":"batrick@batbytes.com","sentAt":"2012-12-12T07:03:56Z","receivedAt":"2012-12-12T07:03:56Z","isPatch":false,"sender":{"key":"batrick@batbytes.com","avatar":null},"body":"Hi Jeff,\n\nOn Wed, Dec 12, 2012 at 1:32 AM, Jeff King <peff@peff.net> wrote:\n> It would take a lot of effort to expose git-core's internals in a clean\n> way; you'd probably be better off starting from scratch and rewriting\n> large parts in a friendly library-like manner. Fortunately, there is\n> already a project underway to do so: libgit2.  It does not yet have\n> feature parity with git, but it can do quite a bit.  And there are\n> already ruby and python bindings.\n\nOf course, this comes back to the issue of whether it's a good idea to\nuse perl/ruby/python as a front-end to regular git commands\n(pull/push/etc.). While, yes, bindings can be made for these\nlanguages, you are now making git depend on the presence of one of\nthese languages in order for git to function. With Lua, the (static)\ndependence is very small yet brings much to git in terms of\nextensibility and maintainability.\n\nAs for Lua's suitability for your (2) point, I admit I'm not familiar\nwith how much \"interacting with the outside world\" the git commands\ndo; however, I would suspect that it is not significant enough to rule\nLua out?\n\n--\n- Patrick Donnelly\n"},{"id":"204720","messageId":"CACh33Fpk8_ZXw8Ladx83J+rmdRYf7ruYAMMkqOKcoH3OApKPJQ@mail.gmail.com","threadId":"32189","inReplyTo":"20121212033043.GA24937@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Patrick Donnelly","fromEmail":"batrick@batbytes.com","sentAt":"2012-12-12T07:11:55Z","receivedAt":"2012-12-12T07:11:55Z","isPatch":false,"sender":{"key":"batrick@batbytes.com","avatar":null},"body":"Hi Eric,\n\nOn Tue, Dec 11, 2012 at 10:30 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> It might be a good fit for extending git; I wouldn't be very surprised if\n> that worked. However, I do have concerns about the \"Oh, we'll just\n> lash together a binding to C\" attitude common among lua programmers; I\n> foresee maintainability problems and the possibility of slow death by\n> low-level details as that strategy tries to scale up.\n\nI think this is quite a prediction? Could you give an example\nscenario? How would another language (e.g. Python) mitigate this?\n\n> And, of course, one problem with calling back into C a lot is that\n> you walk back into C's resource-management issues.\n\nC resource management can be effectively dealt with by relying on\nLua's GC to track C resources via userdata.\n\n> My sense is that git's use cases are better served by a glue language\n> in the Python/Perl/Ruby class rather than an extension langage. But\n> my mind is open on this issue.\n\nI don't see how these languages are more appropriate based on your concerns.\n\n--\n- Patrick Donnelly\n"},{"id":"204721","messageId":"20121212083210.GB18322@sigill.intra.peff.net","threadId":"32189","inReplyTo":"CACh33FrgZhsKp7o9ki6n1AbfRKYYbdLMWuGUGKUqDfH5m0Akng@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-12-12T08:32:11Z","receivedAt":"2012-12-12T08:32:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 12, 2012 at 02:03:56AM -0500, Patrick Donnelly wrote:\n\n> On Wed, Dec 12, 2012 at 1:32 AM, Jeff King <peff@peff.net> wrote:\n> > It would take a lot of effort to expose git-core's internals in a clean\n> > way; you'd probably be better off starting from scratch and rewriting\n> > large parts in a friendly library-like manner. Fortunately, there is\n> > already a project underway to do so: libgit2.  It does not yet have\n> > feature parity with git, but it can do quite a bit.  And there are\n> > already ruby and python bindings.\n> \n> Of course, this comes back to the issue of whether it's a good idea to\n> use perl/ruby/python as a front-end to regular git commands\n> (pull/push/etc.).\n\nYeah, I think that is a separate issue, though. I cannot see us ever\nwriting core commands like \"git pull\" in any scripting language besides\nPOSIX shell due to dependency issues. So language bindings are really\nfor things that are not going to go into git-core, or are ancillary\ncommands that people can live without (e.g., git-add--interactive,\nremote helpers, etc).\n\n> While, yes, bindings can be made for these languages, you are now\n> making git depend on the presence of one of these languages in order\n> for git to function. With Lua, the (static) dependence is very small\n> yet brings much to git in terms of extensibility and maintainability.\n\nAnd I would include Lua in my list of \"I cannot see...\" above. It can be\nstatically linked, so it is not a run-time dependency, but it would\nstill be a build-time dependency. The community has historically been\npretty resistant to dependencies (I do not care too much myself,\nthough).\n\nI think doing anything significant in Lua would have the same problem as\ndoing anything significant in Python: there would need to be substantial\ninternal cleanup to make sane bindings. And again, that is what libgit2\nis doing (and yes, there are Lua bindings for it already).\n\nUsing libgit2 bindings would introduce a new dependency, of course, but\nthat is on par with a Lua dependency.\n\n> As for Lua's suitability for your (2) point, I admit I'm not familiar\n> with how much \"interacting with the outside world\" the git commands\n> do; however, I would suspect that it is not significant enough to rule\n> Lua out?\n\nI did not mean to rule it out for point (2); I only meant that it is\nprobably the only reasonable thing for point (1), whereas for point (2),\nwe have many more options.  I suspect Lua would do just fine given the\nright set of modules, though I tend to prefer other languages myself\nwhen embeddedness is not an issue.\n\nAs for \"interacting with the outside world\", I was specifically thinking\nof stuff like git-send-email (currently in perl) and git-imap-send\n(written in C). They need to open network sockets and speak standard\nprotocols. I suspect Lua would need a module or custom bindings to do\nthe former at all, and certainly the code would be much simpler if we\nre-used standard modules for speaking SMTP and IMAP (which of course\nincreases our dependencies again...).\n\n-Peff\n"},{"id":"204736","messageId":"20121212122355.GA25981@thyrsus.com","threadId":"32189","inReplyTo":"50C811ED.4000600@workspacewhiz.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-12-12T12:23:55Z","receivedAt":"2012-12-12T12:23:55Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Joshua Jensen <jjensen@workspacewhiz.com>:\n> Anyway, my preference is to allow scripts to run in-process within\n> Git, because it is far, far faster on Windows.  I imagine it is\n> faster than forking processes on non-Windows machines, too, but I\n> have no statistics to back that up.\n> \n> Python, Perl, or Ruby can be embedded, too, but Lua probably embeds\n> the easiest and smallest out of those other 3 languages.\n> \n> And shell scripts tend to be the slowest on Windows due to the\n> excessive numbers of process invocations needed to get anything\n> reasonable done.\n\nI don't think there's *any* dimension along which lua is not clearly\nbetter than shell for this sort of thing, so no argument there.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204738","messageId":"20121212122625.GB25981@thyrsus.com","threadId":"32189","inReplyTo":"20121212063208.GA18322@sigill.intra.peff.net","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-12-12T12:26:25Z","receivedAt":"2012-12-12T12:26:25Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Jeff King <peff@peff.net>:\n> I think there are really two separate use cases to consider:\n> \n>   1. Providing snippets of script to Git to get Turing-complete behavior\n>      for existing Git features. For example, selecting commits during a\n>      traversal (e.g., a better \"log --grep\"), formatting output (e.g., a\n>      better \"log --format\" or \"for-each-ref --format\").\n> \n>   2. Writing whole new git commands in a language that is quicker or\n>      easier to develop in than C.\n\nThat's good analysis.  I agree with your use-case split, I guess I'm just not\nvery aware of the places in git where (1) is important.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204739","messageId":"20121212122909.GA21624@sigill.intra.peff.net","threadId":"32189","inReplyTo":"20121212122625.GB25981@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-12-12T12:29:09Z","receivedAt":"2012-12-12T12:29:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 12, 2012 at 07:26:25AM -0500, Eric S. Raymond wrote:\n\n> Jeff King <peff@peff.net>:\n> > I think there are really two separate use cases to consider:\n> > \n> >   1. Providing snippets of script to Git to get Turing-complete behavior\n> >      for existing Git features. For example, selecting commits during a\n> >      traversal (e.g., a better \"log --grep\"), formatting output (e.g., a\n> >      better \"log --format\" or \"for-each-ref --format\").\n> > \n> >   2. Writing whole new git commands in a language that is quicker or\n> >      easier to develop in than C.\n> \n> That's good analysis.  I agree with your use-case split, I guess I'm just not\n> very aware of the places in git where (1) is important.\n\nYeah, I don't think (1) is your use case at all. But when people talk\nabout \"Jeff's lua experiment\", they are talking about some patches I had\nto do (1), which covered \"log --format\" (but ultimately would need more\ncleanup to be acceptable upstream). Maybe that clears up the discussion\na little bit.\n\n-Peff\n"},{"id":"204740","messageId":"20121212124306.GC25981@thyrsus.com","threadId":"32189","inReplyTo":"CACh33Fpk8_ZXw8Ladx83J+rmdRYf7ruYAMMkqOKcoH3OApKPJQ@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-12-12T12:43:06Z","receivedAt":"2012-12-12T12:43:06Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Patrick Donnelly <batrick@batbytes.com>:\n> On Tue, Dec 11, 2012 at 10:30 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> > It might be a good fit for extending git; I wouldn't be very surprised if\n> > that worked. However, I do have concerns about the \"Oh, we'll just\n> > lash together a binding to C\" attitude common among lua programmers; I\n> > foresee maintainability problems and the possibility of slow death by\n> > low-level details as that strategy tries to scale up.\n> \n> I think this is quite a prediction? Could you give an example\n> scenario?\n\nEverything old is new again.  I'm going by experience with Tcl back in the day.\n\n>        How would another language (e.g. Python) mitigate this?\n\nThe way you mitigate this sort of problem is to have a good set of\nhigh-level bindings for standard services (like socket I/O) built in\nyour extension language and using its abstractions, so you don't get a\nproliferation of low-level semi-custom APIs for doing the same stuff.\n\nI have elsewhere referred to this as \"the harsh lesson of Perl\", which\nI do not love but which was the first scripting language to get this\nright.  There is a reason Tcl and a couple of earlier designs like csh\nthat we would now call \"scripting languages\" were displaced by Python\nand Perl; this is it.\n\nMy favorite present-day example of getting this right is the Python bindings\nfor GTK.  They're lovely.  A work of art.\n\n> I don't see how these languages are more appropriate based on your concerns.\n\nYour previous exchange with Jeff King indicates that you don't\nunderstand glue scripting very well.  Your puzzlement here just\nconfirms that.  Trust both of us on this, it's important.  And\nreread my previous three paragraphs.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204761","messageId":"7vpq2f5ffu.fsf@alter.siamese.dyndns.org","threadId":"32189","inReplyTo":"20121212063208.GA18322@sigill.intra.peff.net","subject":"Re: Python extension commands in git - request for policy change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T17:49:09Z","receivedAt":"2012-12-12T17:49:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think there are really two separate use cases to consider:\n>\n>   1. Providing snippets of script to Git to get Turing-complete behavior\n>      for existing Git features. For example, selecting commits during a\n>      traversal (e.g., a better \"log --grep\"), formatting output (e.g., a\n>      better \"log --format\" or \"for-each-ref --format\").\n>\n>   2. Writing whole new git commands in a language that is quicker or\n>      easier to develop in than C.\n>\n> I think (1) is a good match for lua....\n>\n> But for (2), you are going to care a lot more about the language and its\n> ecosystem (because you'll be interacting more with the world outside of\n> git), and about having bindings to lots of different parts of git\n> (because you'll want to do more interesting things than just examine a\n> few data structures).\n\nGood summary.  We also need to realize that adding a native\nsubcommand written in C has become much easier over time as our\ninternal API has evolved and matured.  These days, we still do a\nwhole new command in scripts (and we have whole commands still in\nscripts) not because \"quicker or easier to develop\" (that is still\ntrue for throw-away experiments) but primarily because that is\neasier to modify and experiment over time until we find a solid\ndesign.\n\nAmong the more important subcommands that are still scripts, I think\n\"add -i\", \"repack\", \"pull\", \"stash\" and possibly \"rebase\" have\ninterfaces facing to both the end users and to the core part\nsolidified enough that they can now be ported to C.  Others either\nare not important enough or still have rooms to improve the\ninterfaces in either direction that it would still be better to\nleave them in scripts (e.g. \"bisect\" with \"<used-to-be, now-is> vs\n<good, bad>\" issue unsettled, \"submodule\" with \"floating\" issue\nunsettled, etc.).\n"},{"id":"204786","messageId":"CAH5451nVqnS0UFBVDW5=Xmaj_6geiw7D7J4mR7922U+074W2qQ@mail.gmail.com","threadId":"32189","inReplyTo":"7vpq2f5ffu.fsf@alter.siamese.dyndns.org","subject":"Re: Python extension commands in git - request for policy change","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-12-12T22:21:55Z","receivedAt":"2012-12-12T22:21:55Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 13 December 2012 04:49, Junio C Hamano <gitster@pobox.com> wrote:\n> \"bisect\" with \"<used-to-be, now-is> vs\n> <good, bad>\" issue unsettled\n\nWould you want to see this issue resolved in-script before a porting\nattempt was started?\n\nRegards,\n\nAndrew Ardill\n"},{"id":"204793","messageId":"7vhanq3n97.fsf@alter.siamese.dyndns.org","threadId":"32189","inReplyTo":"CAH5451nVqnS0UFBVDW5=Xmaj_6geiw7D7J4mR7922U+074W2qQ@mail.gmail.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T22:43:16Z","receivedAt":"2012-12-12T22:43:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n> On 13 December 2012 04:49, Junio C Hamano <gitster@pobox.com> wrote:\n>> \"bisect\" with \"<used-to-be, now-is> vs\n>> <good, bad>\" issue unsettled\n>\n> Would you want to see this issue resolved in-script before a porting\n> attempt was started?\n\nHonestly, I do not care too much either way, but for the people who\nwant to work either on the rewrite-to-C or on the semantics issue,\nit would be easier to manage it that way.\n\nAnd that \"issue resolved in-script\" does not have to be \"implemented\nin-script\".  The resolution could be to declare that it is not worth\nit and a promise to call the two states <good, bad> and with no\nother names.  It would give a semantics for the rewriters-to-C can\nstart working on that is stable enough ;-).\n"},{"id":"205169","messageId":"CACh33Fo=FqvVf-P6-FTdv3aXAQMDEN4sVdE8dm_49fnSMreAWA@mail.gmail.com","threadId":"32189","inReplyTo":"20121212124306.GC25981@thyrsus.com","subject":"Re: Python extension commands in git - request for policy change","fromName":"Patrick Donnelly","fromEmail":"batrick@batbytes.com","sentAt":"2012-12-19T02:30:22Z","receivedAt":"2012-12-19T02:30:22Z","isPatch":false,"sender":{"key":"batrick@batbytes.com","avatar":null},"body":"On Wed, Dec 12, 2012 at 7:43 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Patrick Donnelly <batrick@batbytes.com>:\n>>        How would another language (e.g. Python) mitigate this?\n>\n> The way you mitigate this sort of problem is to have a good set of\n> high-level bindings for standard services (like socket I/O) built in\n> your extension language and using its abstractions, so you don't get a\n> proliferation of low-level semi-custom APIs for doing the same stuff.\n>\n> I have elsewhere referred to this as \"the harsh lesson of Perl\", which\n> I do not love but which was the first scripting language to get this\n> right.  There is a reason Tcl and a couple of earlier designs like csh\n> that we would now call \"scripting languages\" were displaced by Python\n> and Perl; this is it.\n\nOkay, I understand what you were trying to say earlier.\n\nI'm not going to say Lua is a silver bullet for all embedded language\nneeds. If you seriously need an exotic suite of libraries built into\nthe language, then Lua is not really going to work well for you. In\nreality though, many projects that require an extension language do\nnot need all the system programming facilities thrown in. In fact,\nmany don't want them due to bloat or security considerations. So, you\ntake on a hyperopic viewpoint by ruling out Lua simply because it\nlacks a suite of system libraries.\n\nWith Jeff's response:\n\n> As for \"interacting with the outside world\", I was specifically thinking\n> of stuff like git-send-email (currently in perl) and git-imap-send\n> (written in C). They need to open network sockets and speak standard\n> protocols. I suspect Lua would need a module or custom bindings to do\n> the former at all, and certainly the code would be much simpler if we\n> re-used standard modules for speaking SMTP and IMAP (which of course\n>increases our dependencies again...).\n\nI would think this can perhaps be exported into another script Lua\ncould exec as needed. Or luasocket may be sufficient. These\ndependencies would need to be examined in detail. I wouldn't recommend\nselecting a language because of one odd network protocol dependency\nsatisfied by an obscure built-in library (I realize Jeff's example was\nexactly that, an example).\n\nOn Wed, Dec 12, 2012 at 7:43 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n>> I don't see how these languages are more appropriate based on your concerns.\n>\n> Your previous exchange with Jeff King indicates that you don't\n> understand glue scripting very well.  Your puzzlement here just\n> confirms that.  Trust both of us on this, it's important.  And\n> reread my previous three paragraphs.\n\nWhat I didn't understand coming into this thread was Git's ecosystem.\nI understand embedded scripting languages very well and have been\nworking with Lua for years.\n\nWhat does puzzle me is your dismissal of Lua because it doesn't have\nthe library suite Python does. Lua is not a system programming\nlanguage and I could argue Python is not really an embedded language.\nI came here to try to stimulate discussion about what Git actually\nneeds/wants from a higher level language. If a small embedded language\nwould fit well, the Lua should be a candidate for consideration.\n\n--\n- Patrick Donnelly\n"}]}