Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output

Johannes Schindelin [off-list ref] writes:

As for the FIXME: If you have a config like this:

	[core]
		Some = where
		over
		the = core.rainbow

git-config -z would output something like this:

	core.some\0where\0core.over\0core.the\0core.rainbow\0

Right?

As you can see, it is quite hard for a parser to find out what is key, and 
what is value. That FIXME is _exactly_ about this dilemma.

IIRC I stated once that -z should output a value of "true" for these 
cases, since they only make sense as booleans. But AFAIR nothing 
conclusive came out of that thread.

I do not remember the thread, but I think that may make sense.
"over = 1", "over = true" etc. cannot be canonicalized to "true"
without knowing core.over is boolean, but core.over by itself
without any assignment cannot be anything but a boolean.

Another possibility, though, is to say:

	core.some\0where\0core.over\0\0core.the\0core.rainbow\0

On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:
Another possibility, though, is to say:

	core.some\0where\0core.over\0\0core.the\0core.rainbow\0

How do you denote empty values then?

[section]
	key=
	key

this are two very different statements atm (e.g. the one is false and
the other one is true).

I still think using two different delimiters is the simplest choice.

Gruesse,
-- 
Frank Lichtenheld [off-list ref]
www: http://www.djpig.de/

Hi,

On Tue, 19 Jun 2007, Frank Lichtenheld wrote:

On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:

quoted

Johannes Schindelin [off-list ref] writes:
Another possibility, though, is to say:

	core.some\0where\0core.over\0\0core.the\0core.rainbow\0

How do you denote empty values then?

[section]
	key=
	key

this are two very different statements atm (e.g. the one is false and
the other one is true).

I still think using two different delimiters is the simplest choice.

Okay, good point. But of course, you have to use a delimiter for the key 
name that cannot be part of the keyname. You picked '\n'. The original was 
'='. Both work.

Ciao,
Dscho

Johannes Schindelin [off-list ref] writes:

Hi,

On Tue, 19 Jun 2007, Frank Lichtenheld wrote:

quoted

On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:

quoted

Johannes Schindelin [off-list ref] writes:
Another possibility, though, is to say:

	core.some\0where\0core.over\0\0core.the\0core.rainbow\0

How do you denote empty values then?

[section]
	key=
	key

this are two very different statements atm (e.g. the one is false and
the other one is true).

I still think using two different delimiters is the simplest choice.

Okay, good point. But of course, you have to use a delimiter for the key 
name that cannot be part of the keyname. You picked '\n'. The original was 
'='. Both work.

In the interest of simplicity, it would appear reasonable to use just
= and not introduce an additional delimiter.  This is similar to how
environments are handled and passed in Unix (though not necessarily
relevant).

-- 
David Kastrup

On Tue, Jun 19, 2007 at 12:09:18PM +0100, Johannes Schindelin wrote:

Okay, good point. But of course, you have to use a delimiter for the key 
name that cannot be part of the keyname. You picked '\n'. The original was 
'='. Both work.

No, they actually don't.

Example:

$ cat .git/config
[foo "bar=baz"]
	key = value
[foo]
	key = key=value
$ git config -l
foo.bar=baz.key=value
foo.key=key=value

So how do I parse that?

Gruesse,
-- 
Frank Lichtenheld [off-list ref]
www: http://www.djpig.de/

Hi,

On Tue, 19 Jun 2007, Frank Lichtenheld wrote:

On Tue, Jun 19, 2007 at 12:09:18PM +0100, Johannes Schindelin wrote:

quoted

Okay, good point. But of course, you have to use a delimiter for the key 
name that cannot be part of the keyname. You picked '\n'. The original was 
'='. Both work.

No, they actually don't.

Right, I completely forgot that we actually allow all kinds of special 
characters, in order to be able to say "branch.<branchname>.merge" for all 
kinds of branchnames.

Incidentally, I think I found a bug:

[foo "bar\nbaz"]
	key = value

gives

foo.barbaz.key=value

Ciao,
Dscho

Johannes Schindelin wrote:

On Tue, 19 Jun 2007, Frank Lichtenheld wrote:

quoted

On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:

quoted

quoted

Another possibility, though, is to say:

	core.some\0where\0core.over\0\0core.the\0core.rainbow\0

How do you denote empty values then?

[section]
	key=
	key

this are two very different statements atm (e.g. the one is false and
the other one is true).

I still think using two different delimiters is the simplest choice.

Okay, good point. But of course, you have to use a delimiter for the key 
name that cannot be part of the keyname. You picked '\n'. The original was 
'='. Both work.

If I remember correctly (and what I checked to be true), while '=' cannot
be part of keyname nor section name, it can be part of subsection name,
therefore it can be part of fuly qualified key name.

The '\n' can _not_ be part of subsection name, therefore it can not be
part of fully qualified key name.

  $ cat > conftest <<EOF
  [section "sub=section"]
       truekey=true
       emptykey=
       novalkey
  EOF

  $ GIT_CONFIG=conftest git-config -l
  section.sub=section.truekey=true
  section.sub=section.emptykey=
  section.sub=section.novalkey

-- 
Jakub Narebski
Poland

On Tue, Jun 19, 2007 at 04:57:21PM +0100, Johannes Schindelin wrote:

[foo "bar\nbaz"]
	key = value
gives

foo.barbaz.key=value

for me this gives

foo.barnbaz.key=value

which is the intended behaviour AFAICT
(you mean the actual string '\' 'n' here, right? '\n' gives a syntax
error, also the intended behaviour)

Gruesse,
-- 
Frank Lichtenheld [off-list ref]
www: http://www.djpig.de/

Hi,

On Tue, 19 Jun 2007, Frank Lichtenheld wrote:

On Tue, Jun 19, 2007 at 04:57:21PM +0100, Johannes Schindelin wrote:

quoted

[foo "bar\nbaz"]
	key = value
gives

foo.barbaz.key=value

for me this gives

foo.barnbaz.key=value

Yes, of course I had to have a typo in my message. *sigh*

The point is, that I would not expect a "\" to be _ignored_. Either 
interpreted, or throwing an error, but just ignored?

Ciao,
Dscho

Johannes Schindelin wrote:

On Tue, 19 Jun 2007, Frank Lichtenheld wrote:

quoted

On Tue, Jun 19, 2007 at 04:57:21PM +0100, Johannes Schindelin wrote:

quoted

quoted

[foo "bar\nbaz"]
	key = value
gives

foo.barbaz.key=value

for me this gives

foo.barnbaz.key=value

Yes, of course I had to have a typo in my message. *sigh*

The point is, that I would not expect a "\" to be _ignored_. Either 
interpreted, or throwing an error, but just ignored?

It is interpreted. Perhaps not what you thought it is interpreted, but 
it is interpreted. '\x' => 'x' for 'x' which are not in some limited 
set. ;-)))

-- 
Jakub Narebski
Poland