# Git global usage and tests 9 messages from 2011-05-30 to 2011-05-31. Participants: Romain Geissler, Jeff King, Miles Bader, Junio C Hamano, Carlos Martín Nieto, Ævar Arnfjörð Bjarmason. Thread: https://gitlist.dev/t/27503 ## Romain Geissler, 2011-05-30 14:58 Subject: Git global usage and tests Message-ID: <754E784F-51C6-4B8D-B15D-3FF8B7AF1321@gmail.com> URL: https://gitlist.dev/e/754E784F-51C6-4B8D-B15D-3FF8B7AF1321%40gmail.com ``` Hello, We 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. Indeed the test t2050-git-dir-relative.sh run : echo changed >top && git --git-dir subdir/.git add top && git --git-dir subdir/.git commit -m topcommit && test -r "${COMMIT_FILE}" But according to the git help, it should have specified a git-dir with --git-dir=value ie git --git-dir=subdir/.git add top Am i wrong or the test must be rewritten ? Romain Geissler ``` ## Jeff King, 2011-05-30 15:36 Subject: Re: Git global usage and tests Message-ID: <20110530153620.GA24431@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110530153620.GA24431%40sigill.intra.peff.net In-Reply-To: <754E784F-51C6-4B8D-B15D-3FF8B7AF1321@gmail.com> ``` On Mon, May 30, 2011 at 04:58:14PM +0200, Romain Geissler wrote: > Indeed the test t2050-git-dir-relative.sh run : > > echo changed >top && > git --git-dir subdir/.git add top && > git --git-dir subdir/.git commit -m topcommit && > test -r "${COMMIT_FILE}" > > But according to the git help, it should have specified a git-dir with --git-dir=value ie > git --git-dir=subdir/.git add top The test is OK. Long options that have a required argument can be expressed as either: --long-option=value or --long-option value Long options with an optional argument must use the first form, as the second one is ambiguous (is "value" the value, or the next option?). Your option parser needs to follow these rules to be compatible with git. Have you considered pulling the parse-options parser from git into libgit2? It's one of the more modularized and lib-ified bits of code in git already. -Peff ``` ## Romain Geissler, 2011-05-30 16:10 Subject: Re: Git global usage and tests Message-ID: URL: https://gitlist.dev/e/B369AA28-DEF2-48F3-8E4E-F387E8A57D26%40gmail.com In-Reply-To: <20110530153620.GA24431@sigill.intra.peff.net> ``` Le 30 mai 2011 à 17:36, Jeff King a écrit : > Your option parser needs to follow these rules to be compatible with > git. Sure, 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. > Have you considered pulling the parse-options parser from git into > libgit2? It's one of the more modularized and lib-ified bits of code in > git already. Yes 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. Romain Geissler ``` ## Jeff King, 2011-05-30 16:12 Subject: Re: Git global usage and tests Message-ID: <20110530161230.GA25291@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110530161230.GA25291%40sigill.intra.peff.net In-Reply-To: ``` On Mon, May 30, 2011 at 06:10:20PM +0200, Romain Geissler wrote: > > Have you considered pulling the parse-options parser from git into > > libgit2? It's one of the more modularized and lib-ified bits of code in > > git already. > > Yes 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. Yeah, good point. Definitely it should not be part of the libgit2 library itself. -Peff ``` ## Miles Bader, 2011-05-31 05:12 Subject: Re: Git global usage and tests Message-ID: URL: https://gitlist.dev/e/buor57f78s0.fsf%40dhlpc061.dev.necel.com In-Reply-To: <20110530161230.GA25291@sigill.intra.peff.net> ``` Jeff King writes: >> Yes 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. > > Yeah, good point. Definitely it should not be part of the libgit2 > library itself. But maybe there's room for another library to hold such things (libgitapp...)? -Miles -- `Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life' (from _A Pattern Language_) ``` ## Junio C Hamano, 2011-05-31 05:19 Subject: Re: Git global usage and tests Message-ID: <7v7h97la4s.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v7h97la4s.fsf%40alter.siamese.dyndns.org In-Reply-To: <20110530161230.GA25291@sigill.intra.peff.net> ``` Jeff King writes: > On Mon, May 30, 2011 at 06:10:20PM +0200, Romain Geissler wrote: > >> > Have you considered pulling the parse-options parser from git into >> > libgit2? It's one of the more modularized and lib-ified bits of code in >> > git already. >> >> Yes 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. > > Yeah, good point. Definitely it should not be part of the libgit2 > library itself. IIRC, libgit2 has a lot looser license than ours, and the core GPLv2 part of C git cannot be directly copied without authors' consent; relicensing of necessary parts of C git needs to be arranged. ``` ## Carlos Martín Nieto, 2011-05-31 09:05 Subject: Re: Git global usage and tests Message-ID: <20110531090554.GE28708@centaur.lab.cmartin.tk> URL: https://gitlist.dev/e/20110531090554.GE28708%40centaur.lab.cmartin.tk In-Reply-To: ``` On Tue, May 31, 2011 at 02:12:47PM +0900, Miles Bader wrote: > Jeff King writes: > >> Yes 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. > > > > Yeah, good point. Definitely it should not be part of the libgit2 > > library itself. > > But maybe there's room for another library to hold such things > (libgitapp...)? There are already several libraries to parse command-line options, though IIRC from the last time I used getopt, git's parse-options is more usable. That could be made into a new library (but which should be git-independent) The git-specific part of figuring out commits and commit ranges could live inside libgit2. Cheers, cmn -- Carlos Martín Nieto | http://cmartin.tk "¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI ``` ## Ævar Arnfjörð Bjarmason, 2011-05-31 11:52 Subject: Re: Git global usage and tests Message-ID: URL: https://gitlist.dev/e/BANLkTinW_se8VAhF9wk3KyzNHVc_wH_PqA%40mail.gmail.com In-Reply-To: <7v7h97la4s.fsf@alter.siamese.dyndns.org> ``` On Tue, May 31, 2011 at 07:19, Junio C Hamano wrote: > Jeff King writes: > >> On Mon, May 30, 2011 at 06:10:20PM +0200, Romain Geissler wrote: >> >>> > Have you considered pulling the parse-options parser from git into >>> > libgit2? It's one of the more modularized and lib-ified bits of code in >>> > git already. >>> >>> Yes 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. >> >> Yeah, good point. Definitely it should not be part of the libgit2 >> library itself. > > IIRC, libgit2 has a lot looser license than ours, and the core GPLv2 part > of C git cannot be directly copied without authors' consent; relicensing > of necessary parts of C git needs to be arranged. Seems like a PITA: $ git log --pretty=format:%an parse-options.[ch] | sort | uniq -c | sort -nr 19 Pierre Habouzit 15 Junio C Hamano 11 René Scharfe 9 Stephen Boyd 7 Jonathan Nieder 4 Johannes Schindelin 2 Michele Ballabio 1 Tuncer Ayaz 1 Thomas Rast 1 Olivier Marin 1 Nanako Shiraishi 1 Miklos Vajna 1 Mike Ralphson 1 Michael J Gruber 1 Mark Lodato 1 Linus Torvalds 1 Jeff King 1 Jake Goulding 1 Giuseppe Scrivano 1 Gary V. Vaughan 1 Christian Couder 1 Carlos Rica 1 Andreas Schwab 1 Alex Riesen ``` ## Jeff King, 2011-05-31 15:04 Subject: Re: Git global usage and tests Message-ID: <20110531150455.GA2594@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110531150455.GA2594%40sigill.intra.peff.net In-Reply-To: ``` On Tue, May 31, 2011 at 01:52:31PM +0200, Ævar Arnfjörð Bjarmason wrote: > > IIRC, libgit2 has a lot looser license than ours, and the core GPLv2 part > > of C git cannot be directly copied without authors' consent; relicensing > > of necessary parts of C git needs to be arranged. > > Seems like a PITA: Some of the permission has already been granted. There is a file in libgit2 documenting who has done so. The set difference is: $ git log --format=%an parse-options.[ch] | sort -u >need $ perl -lne 'print $1 if /^ok\s+(.*) have $ comm -23 need have >remaining; cat remaining Alex Riesen Andreas Schwab Carlos Rica Gary V. Vaughan Giuseppe Scrivano Jake Goulding Jonathan Nieder Mark Lodato Michael J Gruber Michele Ballabio Mike Ralphson Miklos Vajna Nanako Shiraishi Olivier Marin Stephen Boyd Thomas Rast Tuncer Ayaz which gets us halfway there. A few of the remaining contributions are quite small, too: $ git blame --line-porcelain parse-options.c | perl -lne 'print $1 if /author (.*)/' | sort | uniq -c | perl -pe 's/(\d+) /$1\t/' >count $ join -1 1 -2 2 -t "`printf '\t'`" -o "2.1 2.2" remaining count 4 Alex Riesen 3 Andreas Schwab 23 Giuseppe Scrivano 16 Jake Goulding 38 Jonathan Nieder 16 Mark Lodato 7 Michele Ballabio 1 Nanako Shiraishi 1 Olivier Marin 46 Stephen Boyd 24 Thomas Rast 22 Tuncer Ayaz Fixing a typo or tweaking the "static" designator on a function is probably not copyrightable. And some of the medium-sized bits could possibly be dropped. Still, it is nice to be mindful of the contributions of others and get permission from everyone. At any rate, the parse-options code would be linked into the new git2 binary, which should probably be GPL'd, anyway. -Peff ```