Git global usage and tests

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

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

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

On Mon, May 30, 2011 at 06:10:20PM +0200, Romain Geissler wrote:

quoted

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

Jeff King [off-list ref] writes:

quoted

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_)

On Tue, May 31, 2011 at 02:12:47PM +0900, Miles Bader wrote:

Jeff King [off-list ref] writes:

quoted

quoted

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