{"thread":{"id":"5460","subject":"Dropping Git.pm (at least Git.xs)?","startedAt":"2006-09-03T11:34:31Z","lastAt":"2006-09-11T08:58:20Z","messageCount":7,"participants":["Junio C Hamano","Dennis Stosberg","Petr Baudis","Sam Vilain","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"26255","messageId":"7vodtxuqt4.fsf@assigned-by-dhcp.cox.net","threadId":"5460","inReplyTo":null,"subject":"Dropping Git.pm (at least Git.xs)?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-03T11:34:31Z","receivedAt":"2006-09-03T11:34:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was reviewing the \"next\" tonight and ended up reverting a few\npatches that came from Git.pm topic that touched fairly core\npart of the system.\n\nParts of environment.c and sha1_file.c are fairly old code that\nhas \"we start in one repository, do our work and exit\" mentality\npretty much ingrained.  The reverted one was meant to minimally\nwork it around to allow switching between repositories.\n\nThe intention is good, but I felt keeping such hack without\nthinking about what the semantics of switching repositories\nshould mean would harm eventual libification.\n\nIn the ideal world in admittably not so immediate future, I\nwould rather have a honestly libified git that encapsulates\ngit_dir, git_object_dir, git_index_file, etc. into a structure\n(\"struct git_repository\" perhaps) and passes a pointer to it to\nfunctions like has_sha1_file(), get_sha1() and friends.\nProbably to keep the changes manageable, we would start from one\ninstance of \"struct git\" that is the default, and existing\ninterfaces would become thin wrappers that pass the pointer to\nthat default one to the updated functions that are repo aware.\n\nOne great promise Git.pm topic showed, at least from my point of\nview, was consolidation of core-wrapper functions various script\nhad.  In the hindsight, I should have pushed for that\nconsolidation a lot stronger while rejecting Git.xs (I\nunderestimated that Git.xs would introduce such portability\nissues).  After all, existing Perl scripts did things without\nhaving to use any .xs.\n\nSince there is no serious user of Git.pm exists, especially\ngit-mv and git-fmt-merge-msg are now not in Perl anymore, I do\nnot think we are in great hurry to have Git.xs yet.  I would\nexpect that the most major customer of Git.xs to be gitweb\neventually, but to support it in persistent environment (read:\nmod_perl) we would need to have multi-repo infrastructure in\nplace.  And I do not think we want a hacky one.\n\nWhat bothered me most was that has_sha1_file() issue; I think it\nis Ok for read_sha1_file() to return object contents from a\nrepository that is not the current repository even after the\neventual libification that each invocation of a function is told\nin which repository to operate.  After all, we depend on object\nname being a reliable handle to its contents, and if the caller\nhas a name of the object that is not in the current repository\nand wants to get its contents, and if the system happens to know\nthe answer (even when it shouldn't have known -- the reason it\nknows is only because the process happens to have switched to\nthat other repository in the past), not failing the request and\ngive the contents is acceptable.  It could even be considered a\nfeature and would be handy when writing cross repository (albeit\nlimited to local repositories) diff/merge tools, for example.\n\nBut has_sha1_file() is different.  It is used to check if it\nexists in the current repository when the caller knows the\nobject name (and presumably its contents), so that the caller\ncan base its decision on what to do next based on the result.\nIt really should care what repository it is operating in.\n\nThe approach taken by the patch I reverted were minimal patch to\nallow switching, which was OK for get_object() purposes, and did\nnot even attempt to define what the semantics of has_sha1_file()\nand read_sha1_file() should be.\n\nI think being able to switch repositories in a single process is\nimportant needs to be designed, not hacked in.  I am sure there\ncertainly are other things that needs more thought (e.g. how\nshould grafts work across repositories), but I think nobody\nknows what they are because we haven't thought about the issues\nyet.\n\nA few sentences to conclude this message.\n\n - I think the clean-up promise of Git.pm is great (e.g.\n   safe_qx should be part of it not in git-svn alone).\n\n - I think Git.xs was a bit premature and raised the hurdle of\n   cleaning up and consolidating various core-wrappers from\n   existing Perl scripts into Git.pm and have them use Git.pm.\n   It would be nice if we can drop this part for now, and do a\n   bit more Perl-level clean-up first.\n\n - I think \"repository\" abstraction, if we are going to have\n   one, should be designed from the core level if we are going\n   to have it accessible from Git.xs.  Unfortunately I am not\n   ready to invest great time and effort for core level\n   libification at this moment.\n\n\n\n-- \nVGER BF report: U 0.516772\n"},{"id":"26257","messageId":"20060903150305.G50c94aea@leonov.stosberg.net","threadId":"5460","inReplyTo":"7vodtxuqt4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Dropping Git.pm (at least Git.xs)?","fromName":"Dennis Stosberg","fromEmail":"dennis@stosberg.net","sentAt":"2006-09-03T15:03:05Z","receivedAt":"2006-09-03T15:03:05Z","isPatch":false,"sender":{"key":"dennis@stosberg.net","avatar":null},"body":"Junio C Hamano wrote:\n\n> In the ideal world in admittably not so immediate future, I\n> would rather have a honestly libified git that encapsulates\n[...]\n>  - I think the clean-up promise of Git.pm is great (e.g.\n>    safe_qx should be part of it not in git-svn alone).\n> \n>  - I think Git.xs was a bit premature and raised the hurdle of\n>    cleaning up and consolidating various core-wrappers from\n>    existing Perl scripts into Git.pm and have them use Git.pm.\n>    It would be nice if we can drop this part for now, and do a\n>    bit more Perl-level clean-up first.\n\nHaving perl bindings to git internals and sometime in the future to a\nlibified git is a great thing.  It will allow people to do interesting\nthings, quickly trying concepts without having to write any C code.\nAnd I expect that gitweb can be sped up remarkably by using Git.pm (no\nforking, parsing of command output often not necessary, easy caching of\nfrequently cached data across calls, etc)\n\nSo I think there are valid uses for Git.pm.\n\nOn the other hand there are the problems Junio mentioned.  And the\nportability issues wit Git.pm:\n\n - Git has to be built with the same compiler perl was built with,\n   which is a problem on many Solaris machines.\n - We need to generate position-independent code on some archs, but\n   have no proper way to determine on which systems it is really\n   necessary. \n - It completely breaks cross-compiling.\n\nAnd the gain is negligible at the moment: There are only two users\nleft: git-annotate and git-send-email.  The first one has already\nbeen superseded by git-blame and the second one can easily be\nconverted back.\n\nI think Git.pm would be a good candidate for the contrib section if\nthere is someone who keeps it up-to-date through the coming changes.\nThe only thing that would have to be kept in the main Makefile is the\noption to generate position-independent code, defaulting to off.\n\nRegards,\nDennis\n\n\n\n-- \nVGER BF report: U 0.957499\n"},{"id":"26536","messageId":"20060907195107.GD23891@pasky.or.cz","threadId":"5460","inReplyTo":"7vodtxuqt4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Dropping Git.pm (at least Git.xs)?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-07T19:51:07Z","receivedAt":"2006-09-07T19:51:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hi,\n\nDear diary, on Sun, Sep 03, 2006 at 01:34:31PM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n>  - I think the clean-up promise of Git.pm is great (e.g.\n>    safe_qx should be part of it not in git-svn alone).\n> \n>  - I think Git.xs was a bit premature and raised the hurdle of\n>    cleaning up and consolidating various core-wrappers from\n>    existing Perl scripts into Git.pm and have them use Git.pm.\n>    It would be nice if we can drop this part for now, and do a\n>    bit more Perl-level clean-up first.\n> \n>  - I think \"repository\" abstraction, if we are going to have\n>    one, should be designed from the core level if we are going\n>    to have it accessible from Git.xs.  Unfortunately I am not\n>    ready to invest great time and effort for core level\n>    libification at this moment.\n\n  I basically agree on all three points - I will try to submit a patch\nto implement get_object() purely in Git.pm reasonably soon, and will see\nabout introducing some actually designed repository division abstraction\nwhen I get some time. I hope to see Git.xs come back again in few\nmonths, but for now I have to concur that we should go back to the\ndrawing board.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"26688","messageId":"4504529A.70401@vilain.net","threadId":"5460","inReplyTo":"20060903150305.G50c94aea@leonov.stosberg.net","subject":"Re: Dropping Git.pm (at least Git.xs)?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-09-10T17:59:54Z","receivedAt":"2006-09-10T17:59:54Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Dennis Stosberg wrote:\n> Having perl bindings to git internals and sometime in the future to a\n> libified git is a great thing.  It will allow people to do interesting\n> things, quickly trying concepts without having to write any C code.\n> And I expect that gitweb can be sped up remarkably by using Git.pm (no\n> forking, parsing of command output often not necessary, easy caching of\n> frequently cached data across calls, etc)\n\nFWIW, I have been starting on a perl implementation.  It uses the\nGit.pm, but not for anything *that* important.  It's still very young,\nbut once I have reading and writing files basically working, I'll\nrelease it to CPAN separately - no reason it needs to be distributed\nwith Git itself.\n\nSee http://utsl.gen.nz/gitweb/?p=VCS-Git\n\nI used this design to talk about Moose at YAPC::Europe 2006.\nhttp://utsl.gen.nz/talks/moose/start.html\n\nSam.\n"},{"id":"26701","messageId":"ee22lb$uia$1@sea.gmane.org","threadId":"5460","inReplyTo":"4504529A.70401@vilain.net","subject":"Re: Dropping Git.pm (at least Git.xs)?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-10T22:13:01Z","receivedAt":"2006-09-10T22:13:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sam Vilain wrote:\n\n> Dennis Stosberg wrote:\n>> Having perl bindings to git internals and sometime in the future to a\n>> libified git is a great thing.  It will allow people to do interesting\n>> things, quickly trying concepts without having to write any C code.\n>> And I expect that gitweb can be sped up remarkably by using Git.pm (no\n>> forking, parsing of command output often not necessary, easy caching of\n>> frequently cached data across calls, etc)\n> \n> FWIW, I have been starting on a perl implementation.  It uses the\n> Git.pm, but not for anything *that* important.  It's still very young,\n> but once I have reading and writing files basically working, I'll\n> release it to CPAN separately - no reason it needs to be distributed\n> with Git itself.\n> \n> See http://utsl.gen.nz/gitweb/?p=VCS-Git\n\nCould you please put appropriate information on GitWiki\n  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\nPerhaps it would be good time to start new section, Git Implementations,\nand put egit (Java GIT library and Eclipse plugin) there too.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26717","messageId":"20060911032557.GF23891@pasky.or.cz","threadId":"5460","inReplyTo":"ee22lb$uia$1@sea.gmane.org","subject":"Re: Dropping Git.pm (at least Git.xs)?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-11T03:25:57Z","receivedAt":"2006-09-11T03:25:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Sep 10, 2006 at 07:59:54PM CEST, I got a letter\nwhere Sam Vilain <sam@vilain.net> said that...\n> Dennis Stosberg wrote:\n> > Having perl bindings to git internals and sometime in the future to a\n> > libified git is a great thing.  It will allow people to do interesting\n> > things, quickly trying concepts without having to write any C code.\n> > And I expect that gitweb can be sped up remarkably by using Git.pm (no\n> > forking, parsing of command output often not necessary, easy caching of\n> > frequently cached data across calls, etc)\n> \n> FWIW, I have been starting on a perl implementation.  It uses the\n> Git.pm, but not for anything *that* important.  It's still very young,\n> but once I have reading and writing files basically working, I'll\n> release it to CPAN separately - no reason it needs to be distributed\n> with Git itself.\n> \n> See http://utsl.gen.nz/gitweb/?p=VCS-Git\n\nI think those two can coexist quite well. Yours aims for a nice and\nslick object interface, while mine is just about wrapping Git interface\nin Perl, without building any elaborate object model (it would provide\nany only if underlying libgit would in the future, I guess).\n\nNow, I'm not actually opposed to making Git.pm provide more\nobject-oriented interface, and it is thus obvious that it might be due\nto consider a merge of the two modules, but\n\n  (i) Git.pm ought to stay bundled with Git, simply to be useful for Git\nitself and the perl scripts it carries. Without Git.xs and associated\nportability concerns, Git.pm might finally actually help things. :-)\n\n  (ii) People would thus go mad about external dependencies like Moose\nor even Class::Autouse, so Git.pm can't rely on anything like that\n(unless it bundles it, which is not quite practical in case of Moose).\n\n  (iii) (Besides, Moose may be the next totally cool and all-popular\nthing in the world of Perl soon, but so far, I'd be personally careful\nabout using it for the \"official\" interface, since Git Perl developers\nwould apparently have to learn another way to do objects in Perl before\nable to use Git, and other Perl developers going by couldn't read (and\nfix/enhance) the code without doing the same.)\n\n\nDear diary, on Mon, Sep 11, 2006 at 12:13:01AM CEST, I got a letter\nwhere Jakub Narebski <jnareb@gmail.com> said that...\n> Could you please put appropriate information on GitWiki\n>   http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\n> Perhaps it would be good time to start new section, Git Implementations,\n> and put egit (Java GIT library and Eclipse plugin) there too.\n\nThis really isn't a Git reimplementation (thankfully).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"26727","messageId":"ee38f8$pp8$1@sea.gmane.org","threadId":"5460","inReplyTo":"20060911032557.GF23891@pasky.or.cz","subject":"Re: Dropping Git.pm (at least Git.xs)?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-11T08:58:20Z","receivedAt":"2006-09-11T08:58:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n\n> Dear diary, on Mon, Sep 11, 2006 at 12:13:01AM CEST, I got a letter\n> where Jakub Narebski <jnareb@gmail.com> said that...\n>> Could you please put appropriate information on GitWiki\n>>   http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\n>> Perhaps it would be good time to start new section, Git Implementations,\n>> and put egit (Java GIT library and Eclipse plugin) there too.\n> \n> This really isn't a Git reimplementation (thankfully).\n\nPerhaps \"language binding\" would be better name...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}