Git global usage and tests

Git global usage and tests

[Romain Geissler]

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

Re: Git global usage and tests

[Jeff King]

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

Re: Git global usage and tests

[Romain Geissler]

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

Re: Git global usage and tests

[Jeff King]

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

Re: Git global usage and tests

[Miles Bader]

Jeff King <peff@peff.net> 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_)

Re: Git global usage and tests

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

On Tue, May 31, 2011 at 02:12:47PM +0900, Miles Bader wrote:
> Jeff King <peff@peff.net> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Git global usage and tests

[Junio C Hamano]

Jeff King <peff@peff.net> 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.

Re: Git global usage and tests

[Ævar Arnfjörð Bjarmason]

On Tue, May 31, 2011 at 07:19, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> 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

Re: Git global usage and tests

[Jeff King]

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+(.*) </' libgit2/git.git-authors >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