{"thread":{"id":"27503","subject":"Git global usage and tests","startedAt":"2011-05-30T14:58:14Z","lastAt":"2011-05-31T15:04:55Z","messageCount":9,"participants":["Romain Geissler","Jeff King","Miles Bader","Junio C Hamano","Carlos Martín Nieto","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"169002","messageId":"754E784F-51C6-4B8D-B15D-3FF8B7AF1321@gmail.com","threadId":"27503","inReplyTo":null,"subject":"Git global usage and tests","fromName":"Romain Geissler","fromEmail":"romain.geissler@gmail.com","sentAt":"2011-05-30T14:58:14Z","receivedAt":"2011-05-30T14:58:14Z","isPatch":false,"sender":{"key":"romain.geissler@gmail.com","avatar":null},"body":"Hello,\n\nWe are currently coding a minimal git client using libgit2, and as quoted by David Glesser in another mail, we use the git test base on our client to validate it. We found a test that tries to run git with a specified --git-dir but don't use the way it's described in the help.\n\nIndeed the test t2050-git-dir-relative.sh run :\n\necho changed >top &&\ngit --git-dir subdir/.git add top &&\ngit --git-dir subdir/.git commit -m topcommit &&\ntest -r \"${COMMIT_FILE}\"\n\nBut according to the git help, it should have specified a git-dir with --git-dir=value ie\ngit --git-dir=subdir/.git add top\n\nAm i wrong or the test must be rewritten ?\n\nRomain Geissler"},{"id":"169004","messageId":"20110530153620.GA24431@sigill.intra.peff.net","threadId":"27503","inReplyTo":"754E784F-51C6-4B8D-B15D-3FF8B7AF1321@gmail.com","subject":"Re: Git global usage and tests","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-30T15:36:20Z","receivedAt":"2011-05-30T15:36:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 30, 2011 at 04:58:14PM +0200, Romain Geissler wrote:\n\n> Indeed the test t2050-git-dir-relative.sh run :\n> \n> echo changed >top &&\n> git --git-dir subdir/.git add top &&\n> git --git-dir subdir/.git commit -m topcommit &&\n> test -r \"${COMMIT_FILE}\"\n> \n> But according to the git help, it should have specified a git-dir with --git-dir=value ie\n> git --git-dir=subdir/.git add top\n\nThe test is OK. Long options that have a required argument can be\nexpressed as either:\n\n --long-option=value\n\nor\n\n --long-option value\n\nLong options with an optional argument must use the first form, as the\nsecond one is ambiguous (is \"value\" the value, or the next option?).\n\nYour option parser needs to follow these rules to be compatible with\ngit. Have you considered pulling the parse-options parser from git into\nlibgit2? It's one of the more modularized and lib-ified bits of code in\ngit already.\n\n-Peff\n"},{"id":"169008","messageId":"B369AA28-DEF2-48F3-8E4E-F387E8A57D26@gmail.com","threadId":"27503","inReplyTo":"20110530153620.GA24431@sigill.intra.peff.net","subject":"Re: Git global usage and tests","fromName":"Romain Geissler","fromEmail":"romain.geissler@gmail.com","sentAt":"2011-05-30T16:10:20Z","receivedAt":"2011-05-30T16:10:20Z","isPatch":false,"sender":{"key":"romain.geissler@gmail.com","avatar":null},"body":"\nLe 30 mai 2011 à 17:36, Jeff King a écrit :\n\n> Your option parser needs to follow these rules to be compatible with\n> git.\n\nSure, according to our mentor teacher (Matthieu Moy) parse-option can handle both if the command is followed by a required argument, we just need to specify it.\n\n> Have you considered pulling the parse-options parser from git into\n> libgit2? It's one of the more modularized and lib-ified bits of code in\n> git already.\n\nYes and No. We have already copied some code from git : parse-option, the error handling functions, a part of the run-command block and a part of the compatibility layer. To my mind, there is no reason to pull it into libgit2 as it's only a client feature that works on strings, and libgit2 does not aim at being a client, only a git library.\n\nRomain Geissler"},{"id":"169009","messageId":"20110530161230.GA25291@sigill.intra.peff.net","threadId":"27503","inReplyTo":"B369AA28-DEF2-48F3-8E4E-F387E8A57D26@gmail.com","subject":"Re: Git global usage and tests","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-30T16:12:30Z","receivedAt":"2011-05-30T16:12:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 30, 2011 at 06:10:20PM +0200, Romain Geissler wrote:\n\n> > Have you considered pulling the parse-options parser from git into\n> > libgit2? It's one of the more modularized and lib-ified bits of code in\n> > git already.\n> \n> Yes and No. We have already copied some code from git : parse-option,\n> the error handling functions, a part of the run-command block and a\n> part of the compatibility layer. To my mind, there is no reason to\n> pull it into libgit2 as it's only a client feature that works on\n> strings, and libgit2 does not aim at being a client, only a git\n> library.\n\nYeah, good point. Definitely it should not be part of the libgit2\nlibrary itself.\n\n-Peff\n"},{"id":"169039","messageId":"buor57f78s0.fsf@dhlpc061.dev.necel.com","threadId":"27503","inReplyTo":"20110530161230.GA25291@sigill.intra.peff.net","subject":"Re: Git global usage and tests","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-05-31T05:12:47Z","receivedAt":"2011-05-31T05:12:47Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jeff King writes:\n>> Yes and No. We have already copied some code from git : parse-option,\n>> the error handling functions, a part of the run-command block and a\n>> part of the compatibility layer. To my mind, there is no reason to\n>> pull it into libgit2 as it's only a client feature that works on\n>> strings, and libgit2 does not aim at being a client, only a git\n>> library.\n>\n> Yeah, good point. Definitely it should not be part of the libgit2\n> library itself.\n\nBut maybe there's room for another library to hold such things\n(libgitapp...)?\n\n-Miles\n\n-- \n`Cars give people wonderful freedom and increase their opportunities.\n But they also destroy the environment, to an extent so drastic that\n they kill all social life' (from _A Pattern Language_)\n"},{"id":"169040","messageId":"7v7h97la4s.fsf@alter.siamese.dyndns.org","threadId":"27503","inReplyTo":"20110530161230.GA25291@sigill.intra.peff.net","subject":"Re: Git global usage and tests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-31T05:19:47Z","receivedAt":"2011-05-31T05:19:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, May 30, 2011 at 06:10:20PM +0200, Romain Geissler wrote:\n>\n>> > Have you considered pulling the parse-options parser from git into\n>> > libgit2? It's one of the more modularized and lib-ified bits of code in\n>> > git already.\n>> \n>> Yes and No. We have already copied some code from git : parse-option,\n>> the error handling functions, a part of the run-command block and a\n>> part of the compatibility layer. To my mind, there is no reason to\n>> pull it into libgit2 as it's only a client feature that works on\n>> strings, and libgit2 does not aim at being a client, only a git\n>> library.\n>\n> Yeah, good point. Definitely it should not be part of the libgit2\n> library itself.\n\nIIRC, libgit2 has a lot looser license than ours, and the core GPLv2 part\nof C git cannot be directly copied without authors' consent; relicensing\nof necessary parts of C git needs to be arranged.\n"},{"id":"169045","messageId":"20110531090554.GE28708@centaur.lab.cmartin.tk","threadId":"27503","inReplyTo":"buor57f78s0.fsf@dhlpc061.dev.necel.com","subject":"Re: Git global usage and tests","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-05-31T09:05:54Z","receivedAt":"2011-05-31T09:05:54Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Tue, May 31, 2011 at 02:12:47PM +0900, Miles Bader wrote:\n> Jeff King writes:\n> >> Yes and No. We have already copied some code from git : parse-option,\n> >> the error handling functions, a part of the run-command block and a\n> >> part of the compatibility layer. To my mind, there is no reason to\n> >> pull it into libgit2 as it's only a client feature that works on\n> >> strings, and libgit2 does not aim at being a client, only a git\n> >> library.\n> >\n> > Yeah, good point. Definitely it should not be part of the libgit2\n> > library itself.\n> \n> But maybe there's room for another library to hold such things\n> (libgitapp...)?\n\nThere are already several libraries to parse command-line options,\nthough IIRC from the last time I used getopt, git's parse-options is\nmore usable. That could be made into a new library (but which should\nbe git-independent)\n\nThe git-specific part of figuring out commits and commit ranges could\nlive inside libgit2.\n\nCheers,\n cmn\n-- \nCarlos Martín Nieto | http://cmartin.tk\n\n\"¿Cómo voy a decir bobadas si soy mudo?\" -- CACHAI\n"},{"id":"169048","messageId":"BANLkTinW_se8VAhF9wk3KyzNHVc_wH_PqA@mail.gmail.com","threadId":"27503","inReplyTo":"7v7h97la4s.fsf@alter.siamese.dyndns.org","subject":"Re: Git global usage and tests","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-05-31T11:52:31Z","receivedAt":"2011-05-31T11:52:31Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, May 31, 2011 at 07:19, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> On Mon, May 30, 2011 at 06:10:20PM +0200, Romain Geissler wrote:\n>>\n>>> > Have you considered pulling the parse-options parser from git into\n>>> > libgit2? It's one of the more modularized and lib-ified bits of code in\n>>> > git already.\n>>>\n>>> Yes and No. We have already copied some code from git : parse-option,\n>>> the error handling functions, a part of the run-command block and a\n>>> part of the compatibility layer. To my mind, there is no reason to\n>>> pull it into libgit2 as it's only a client feature that works on\n>>> strings, and libgit2 does not aim at being a client, only a git\n>>> library.\n>>\n>> Yeah, good point. Definitely it should not be part of the libgit2\n>> library itself.\n>\n> IIRC, libgit2 has a lot looser license than ours, and the core GPLv2 part\n> of C git cannot be directly copied without authors' consent; relicensing\n> of necessary parts of C git needs to be arranged.\n\nSeems like a PITA:\n\n$ git log --pretty=format:%an parse-options.[ch] | sort | uniq -c | sort -nr\n 19 Pierre Habouzit\n 15 Junio C Hamano\n 11 René Scharfe\n 9 Stephen Boyd\n 7 Jonathan Nieder\n 4 Johannes Schindelin\n 2 Michele Ballabio\n 1 Tuncer Ayaz\n 1 Thomas Rast\n 1 Olivier Marin\n 1 Nanako Shiraishi\n 1 Miklos Vajna\n 1 Mike Ralphson\n 1 Michael J Gruber\n 1 Mark Lodato\n 1 Linus Torvalds\n 1 Jeff King\n 1 Jake Goulding\n 1 Giuseppe Scrivano\n 1 Gary V. Vaughan\n 1 Christian Couder\n 1 Carlos Rica\n 1 Andreas Schwab\n 1 Alex Riesen\n"},{"id":"169051","messageId":"20110531150455.GA2594@sigill.intra.peff.net","threadId":"27503","inReplyTo":"BANLkTinW_se8VAhF9wk3KyzNHVc_wH_PqA@mail.gmail.com","subject":"Re: Git global usage and tests","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-31T15:04:55Z","receivedAt":"2011-05-31T15:04:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 31, 2011 at 01:52:31PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > IIRC, libgit2 has a lot looser license than ours, and the core GPLv2 part\n> > of C git cannot be directly copied without authors' consent; relicensing\n> > of necessary parts of C git needs to be arranged.\n> \n> Seems like a PITA:\n\nSome of the permission has already been granted. There is a file in\nlibgit2 documenting who has done so. The set difference is:\n\n $ git log --format=%an parse-options.[ch] | sort -u >need\n $ perl -lne 'print $1 if /^ok\\s+(.*) have\n $ comm -23 need have >remaining; cat remaining\n Alex Riesen\n Andreas Schwab\n Carlos Rica\n Gary V. Vaughan\n Giuseppe Scrivano\n Jake Goulding\n Jonathan Nieder\n Mark Lodato\n Michael J Gruber\n Michele Ballabio\n Mike Ralphson\n Miklos Vajna\n Nanako Shiraishi\n Olivier Marin\n Stephen Boyd\n Thomas Rast\n Tuncer Ayaz\n\nwhich gets us halfway there. A few of the remaining contributions are\nquite small, too:\n\n $ git blame --line-porcelain parse-options.c |\n perl -lne 'print $1 if /author (.*)/' |\n sort | uniq -c |\n perl -pe 's/(\\d+) /$1\\t/' >count\n $ join -1 1 -2 2 -t \"`printf '\\t'`\" -o \"2.1 2.2\" remaining count\n 4 Alex Riesen\n 3 Andreas Schwab\n 23 Giuseppe Scrivano\n 16 Jake Goulding\n 38 Jonathan Nieder\n 16 Mark Lodato\n 7 Michele Ballabio\n 1 Nanako Shiraishi\n 1 Olivier Marin\n 46 Stephen Boyd\n 24 Thomas Rast\n 22 Tuncer Ayaz\n\nFixing a typo or tweaking the \"static\" designator on a function is\nprobably not copyrightable. And some of the medium-sized bits could\npossibly be dropped. Still, it is nice to be mindful of the\ncontributions of others and get permission from everyone.\n\nAt any rate, the parse-options code would be linked into the new git2\nbinary, which should probably be GPL'd, anyway.\n\n-Peff\n"}]}