Get rid of .git/branches/ and .git/remotes/?

Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

I just had a crazy idea. Since we have a framework in place to read/write 
.git/config, I thought that maybe it would be a nice thing to move the 
information which is in .git/branches or .git/remotes into the config.

Advantages:

- it would be easy to copy your private configuration by copying just one 
  file,

- it would be easy to add a switch to git-fetch/git-pull to actually
  store/update the URL and head mapping under a certain nick,

- we could get rid of some parsing code, and

- it would arguably be more consistent.

Disadvantage:

- I know, I know, yet another change to the location of this 
  information...

- (very lame) you could not find out which nicks you have stored with "ls"

Comments?

Ciao,
Dscho

P.S.: I did not yet say anything about .git/info/, did I?

Re: Get rid of .git/branches/ and .git/remotes/?

[Linus Torvalds]

On Sun, 20 Nov 2005, Johannes Schindelin wrote:
> 
> I just had a crazy idea. Since we have a framework in place to read/write 
> .git/config, I thought that maybe it would be a nice thing to move the 
> information which is in .git/branches or .git/remotes into the config.

I considered it, but thee thing is, it really wants "nested names", ie 
having multi-level base-names for the variables. At the same time, I 
absolutely _abhor_ horrible crap like XML, which make nesting a 
fundamental part of their structure.

XML may be "logical", but it has absolutely zero to do with being 
human-readable and clean. In short, XML is total and absolute CRAP (in 
fact, the "X" in "XML" stands for "Crap", but the XML designers were also 
incredibly bad spellers).

So while the basic notion of the git ini file does support nesting (we 
could just make variable names be "base.level1.final" or any number of 
levels deep), I don't know what a sane format would be. I have one 
suggestion that in my opinion "fits" the .ini file syntax (see below), but 
people may well hate it.

Basically I've considered saying that one or more '.' characters at the 
start of a section name would mean "re-use the previous one", so we could 
have (this is a really bad example, just to show the implications):

	[core]
		[.values]
			fixed = true
			nested = fine
			[..example]
				test = Hell yes
		[.other]
			example = strange
		[.]
			name = hi

	[section]
		example = yet another

and that would result in a parse of

	core.values.fixed = true
	core.values.nested = fine
	core.values.example.test = Hell yes
	core.other.example = strange
	core.name = hi
	secontion.example = yet another

and that seems reasonably clean. I'd also allow explicit 
multi-level section names:

	[core.values]
		fixed = true

so you could always write the above config file in an alternate format:

	[core.values] fixed = true
	[core.values] nested = fine
	[core.values.example] test = Hell yes
	[core.other] example = strange
	[core] name = hi
	[section] example = yet another

instead, using no implicit nesting at all (or, indeed, even re-using 
sections like "core.values").

That would allow things like

	[branches]
		[.origin]
			url = master.kernel.org:/pub/scm/git/git.git
			pull = master:origin
		[.mine]
			url = my.domain.com:/other/repo
			pull = master:mine

(which could also be written as

	[branches.origin]
		url = master.kernel.org:/pub/scm/git/git.git
		pull = master:origin

	[branches.mine]
		url = my.domain.com:/other/repo
		pull = master:mine

and the following mixed-indentation usage would be technically correct, 
but perhaps crazy:

	[branches.origin]
		url = master.kernel.org:/pub/scm/git/git.git
		pull = master:origin

	    [.mine]
		url = my.domain.com:/other/repo
		pull = master:mine

Basically, right now we only allow alphanumeric characters in the base 
name, and a new section name completely clears the old one. The above 
would be a very simple extension of that: we would allow '.' in addition 
to alphanumerics, and any initial '.' characters would _keep_ that many 
levels of the old name.

I dunno. That seems a nice extension, and it would make these things 
very unambiguous. But how do other .ini-file-like things do this?

And I'm not 100% convinced that putting these branches in the config file 
has any real advantages over keeping them as separate files. Having 
everything in one place is nice, of course, and being able to copy just 
one file around might be convenient, but it _does_ make the config file 
more complicated.

Anyway, if you want to play with this, here's a trivial patch that may or 
may not work.

		Linus

----
diff --git a/config.c b/config.c
index 915bb97..3b9f300 100644
--- a/config.c
+++ b/config.c
@@ -136,6 +136,19 @@ static int get_base_var(char *name)
 			return -1;
 		if (c == ']')
 			return baselen;
+		if (c == '.') {
+			if (!baselen || name[baselen-1] == '.') {
+				for (;;) {
+					if (!name[baselen])
+						return -1;
+					if (name[baselen++] == '.')
+						break;
+				}
+				continue;
+			}
+			name[baselen++] = c;
+			continue;
+		}
 		if (!isalnum(c))
 			return -1;
 		if (baselen > MAXNAME / 2)

Re: Get rid of .git/branches/ and .git/remotes/?

[Sven Verdoolaege]

On Sun, Nov 20, 2005 at 10:09:50AM -0800, Linus Torvalds wrote:
> and that would result in a parse of
> 
> 	core.values.fixed = true
> 	core.values.nested = fine
> 	core.values.example.test = Hell yes
> 	core.other.example = strange
> 	core.name = hi
> 	secontion.example = yet another
> 

[..]

> I dunno. That seems a nice extension, and it would make these things 
> very unambiguous. But how do other .ini-file-like things do this?

Not sure if this falls in the ".ini-file-like" category, but
YAML (www.yaml.org) does nesting based on indentation.
Your example would look like

core:
  values:
    fixed: true
    nested: fine
    example:
      test: Hell yes
  other:
    example: strange
  name: hi
secontion:
  example: yet another

or

core:
  values: { fixed: true, nested: fine, example: { test: Hell yes } }
  other: { example: strange }
  name: hi
secontion: { example: 'yet another' }

skimo

Re: Get rid of .git/branches/ and .git/remotes/?

[Linus Torvalds]

On Sun, 20 Nov 2005, Sven Verdoolaege wrote:
> 
> Not sure if this falls in the ".ini-file-like" category, but
> YAML (www.yaml.org) does nesting based on indentation.

The main reason I don't like indentation is that it tends to have strange 
rules for "tab". Some people (incorrectly, of course) think that tabs are 
not at fixed 8-byte things, so deciding the indentation of a tab often 
ends up either disallowing tabs altogether (bad) or having other strange 
rules (disallowing spaces).

So I'm not religiously opposed to it, but I find it to be less than 
optimal.

I'd rather have just _pure_ braces, but while that is natural to 
programmers, it's not very natural to most users, I think.

		Linus

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

Linus Torvalds wrote:
> 
> I'd rather have just _pure_ braces, but while that is natural to 
> programmers, it's not very natural to most users, I think.
> 

Sysadmins should be used to braces too (xinetd, dhcpd, named...).

How many office clerks do you expect to use git?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Sun, 20 Nov 2005, Linus Torvalds wrote:

> 	[branches.origin]
> 		url = master.kernel.org:/pub/scm/git/git.git
> 		pull = master:origin
> 
> 	[branches.mine]
> 		url = my.domain.com:/other/repo
> 		pull = master:mine

I like this approach best. In fact, that was my idea on how to go about 
implementing that feature.

However, 

> 	[branches.origin]
> 		url = master.kernel.org:/pub/scm/git/git.git
> 		pull = master:origin
> 
> 	    [.mine]
> 		url = my.domain.com:/other/repo
> 		pull = master:mine

I don't like this. Usually, data in ini files is not dependent on its 
position in the file, with the notable exception of section names. I never 
ran across nested sections (probably for all the reasons XML is 
unreadable). And the sections should be exchangable, just for clarities 
sake.

> And I'm not 100% convinced that putting these branches in the config file 
> has any real advantages over keeping them as separate files. Having 
> everything in one place is nice, of course, and being able to copy just 
> one file around might be convenient, but it _does_ make the config file 
> more complicated.

And it _does_ make finding the information for less savvy git users more 
easy.

I'm not 100% convinced, either, but it could be a better concept than 
different files in different places and different formats basically doing 
the same.

But my thinking went like this: if Pasky and Junio can not agree on one 
location and format, and therefore none of the two is deprecated, how 
about giving them a way out they both might be able to agree to?

Ciao,
Dscho

P.S.: Anybody noticed that I did not use 0xb4 in five days?

Re: Get rid of .git/branches/ and .git/remotes/?

[Josef Weidendorfer]

On Sunday 20 November 2005 19:09, Linus Torvalds wrote:
> 	[branches.origin]
> 		url = master.kernel.org:/pub/scm/git/git.git
> 		pull = master:origin

Two things:
* base names are case insensitive. Repository shortcuts are case
sensitive (and head names, too)
* to get rid of .git/branches/XXX, XXX has to be allowed as
base name. But XXX can contain anything a head name can (including ".").

Not really a problem. Use the ' for ' syntax:

[remotes]
	url = master.kernel.org:/pub/scm/git/git.git for origin
	pull = master:origin for origin

Not really nice. We can not have "for" as head name.

Josef

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Mon, 21 Nov 2005, Josef Weidendorfer wrote:

> On Sunday 20 November 2005 19:09, Linus Torvalds wrote:
> > 	[branches.origin]
> > 		url = master.kernel.org:/pub/scm/git/git.git
> > 		pull = master:origin
> 
> Two things:
> * base names are case insensitive. Repository shortcuts are case
> sensitive (and head names, too)
> * to get rid of .git/branches/XXX, XXX has to be allowed as
> base name. But XXX can contain anything a head name can (including ".").

Is it that important that nicks can be case sensitive or contain spaces or 
dots? I.e. is it sensible to make a difference between

	git pull Weidendorfer

and

	git pull weidendorfer
???

Also, I'd rather write

	git pull josef

than

	git pull "Josef Weidendorfer, III"

> Not really a problem. Use the ' for ' syntax:
> 
> [remotes]
> 	url = master.kernel.org:/pub/scm/git/git.git for origin
> 	pull = master:origin for origin
> 
> Not really nice. We can not have "for" as head name.

Not really nice. Looks ugly. Violates DRY. ("for blabla" would not need to 
be a problem; just enforce quotes around the name.)

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[linux]

> The main reason I don't like indentation is that it tends to have strange 
> rules for "tab". Some people (incorrectly, of course) think that tabs are 
> not at fixed 8-byte things, so deciding the indentation of a tab often 
> ends up either disallowing tabs altogether (bad) or having other strange 
> rules (disallowing spaces).
> 
> So I'm not religiously opposed to it, but I find it to be less than 
> optimal.

Actually, most indentation-sensitive languages have a simpler solution:
they don't try to convert whitespace strings to a number like "horizontal
position"; they just compare strings.

Each line must either have the same indentation string as some active
scope, or its indentation must have the current innermost scope as a
prefix, in which case it introduces a new scope.

This allows anything except for

foo		# No prefix
    bar		# 4 spaces prefix
	baz	# tab prefix: illegal!

The "baz" line would have to begin with 4 spaces to be legal.
They could be followed by 4 more spaces, or a tab, or any other
whitespace pattern.

It's also possible to combine the two, as Haskell does.  Haskell inserts
open braces automatically if there is no such punctuation between two
lines with differing indentation, but if you supply a brace explicitly,
you can do whatever indentation you like.  (And the close brace must be
explicit if the open brace is, of course.)

Re: Get rid of .git/branches/ and .git/remotes/?

[Linus Torvalds]

On Mon, 21 Nov 2005, linux@horizon.com wrote:
> 
> Actually, most indentation-sensitive languages have a simpler solution:
> they don't try to convert whitespace strings to a number like "horizontal
> position"; they just compare strings.

Yes, but that doesn't really change the problem: you can't _visually_ see 
what is wrong in most editors (some editors end up showing tabs as 
something that isn't quite whitespace, but that's also really irritating).

This is like Makefiles: if you have spaces in the wrong place, it may all 
_look_ fine, but the Makefile just doesn't work. Really irritating.

And obviously using the file will show the problem (the parser will 
complain with a nice line number and readable error, hopefully), but I 
personally find that to just be too damn late. By then, you're already 
irritated.

So I like the notion of depending on indentation, but I just feel it falls 
down in practice. 

Of course, since I believe that tabs are always exactly 8 characters, I'd 
also be perfectly happy to just declare that anybody who disagrees with me 
is a moron and deserves to die (*).

		Linus

(*) That's obviously true of _anything_ that people disagree with me on,
but at the same time, I have this nagging suspicion that it's just better 
to not depend on indentation.

Re: Get rid of .git/branches/ and .git/remotes/?

[linux]

> This is like Makefiles: if you have spaces in the wrong place, it may all 
> _look_ fine, but the Makefile just doesn't work. Really irritating.

Makefiles are more annoying because spaces instead of tabs can cause
them to work *differently*.  It's hard to write syntax that will
actually do that, but the parser ahs to go past the problem a bit to
really figure it out, so it can't print a nice error message.

With the strict prefix convention, the parser can produce excellent
error messages.

> And obviously using the file will show the problem (the parser will 
> complain with a nice line number and readable error, hopefully), but I 
> personally find that to just be too damn late. By then, you're already 
> irritated.
>
> So I like the notion of depending on indentation, but I just feel it falls 
> down in practice. 

So you're a crotchety old fart already, unable to learn new things?

It irritates you the first few times until you learn to do it right in 
first place, just like it irritates most beginning C programmers that the
compiler keeps complaining about missing semicolons.

Computers will be annoying about syntax until they learn to do what
I want them to do rather than what I tell them to do, at which point
they'll be smart enough to start being annoying by doing what they want
to to instead of what I want them to do.

> Of course, since I believe that tabs are always exactly 8 characters, I'd 
> also be perfectly happy to just declare that anybody who disagrees with me 
> is a moron and deserves to die (*).

I agree on the One True Tab Spacing, but I fear I heretically
disagree with you about the whole NO_IRQ thing, so I guess I'll just
have to take your advice and start stalking you with eugenic intent.

[Briefly: what hardware conventions are, and particularly how many
of those hardware devices exist in the world, is irrelevant.  We have
existence proofs of hardware that uses 0 for "no IRQ" and hardware that
accepts 0 as a valid IRQ.  dev->irq is a freaking *software convention*.
What matters is the development and maintenance burden of translating
that convention into all the different hardware out there.  And frankly
converting between "0 is valid" and "0 is invalid" affects a lot more
code paths than converting between "0 is invalid" and "-1 is invalid"
for a couple of specific hardware devices.  Particularly if you
want various kernel messages and /proc/interrupts to look right.

Hell, I could argue that having the most common hardware exercise the
longest code paths is a good thing, because that puts the code that
needs the most testing where it'll get it.]


Seriously, you could always have it print warning messages but try to
keep going by assuming 8 space tabs so that at least you can postpone
fixing the problem until your current train of thought has pulled into
the station.

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

linux@horizon.com wrote:
> Actually, most indentation-sensitive languages have a simpler solution:
> they don't try to convert whitespace strings to a number like "horizontal
> position"; they just compare strings.
> 
> Each line must either have the same indentation string as some active
> scope, or its indentation must have the current innermost scope as a
> prefix, in which case it introduces a new scope.
> 
> This allows anything except for
> 
> foo		# No prefix
>     bar		# 4 spaces prefix
> 	baz	# tab prefix: illegal!
> 
> The "baz" line would have to begin with 4 spaces to be legal.
> They could be followed by 4 more spaces, or a tab, or any other
> whitespace pattern.
> 

So, would this be considered legal or would it barf on baz?

foo		# No prefix
	bar	# tab prefix
        baz     # 8 spaces prefix

Most people have tabsize at 8. Some don't. Some editors insert spaces
instead of tabs while others don't. If we just match strings we'll
end up with users sending bug-reports by cut'n pasting their perfectly
valid-looking config which mixes tabs and spaces just because it's
been edited by people using different editors.

Real fun would be if the mta sends tabs as spaces. Then there'd
be no way at all of telling if the config *is* valid or not.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

linux@horizon.com wrote:
>>This is like Makefiles: if you have spaces in the wrong place, it may all 
>>_look_ fine, but the Makefile just doesn't work. Really irritating.
> 
> 
> Makefiles are more annoying because spaces instead of tabs can cause
> them to work *differently*.  It's hard to write syntax that will
> actually do that, but the parser ahs to go past the problem a bit to
> really figure it out, so it can't print a nice error message.
> 
> With the strict prefix convention, the parser can produce excellent
> error messages.
> 

Excellent error messages aren't good enough. It's ok for Python, since 
that's a programming language. We can expect infinitely more from 
programmers than we can from users.

> It irritates you the first few times until you learn to do it right in 
> first place, just like it irritates most beginning C programmers that the
> compiler keeps complaining about missing semicolons.
> 

If I'm trying out some new stuff that annoys me three times without me 
seeing an obvious error on my part (in the editor of my choice) I 
usually write it down as broken and move on.

> Computers will be annoying about syntax until they learn to do what
> I want them to do rather than what I tell them to do, at which point
> they'll be smart enough to start being annoying by doing what they want
> to to instead of what I want them to do.
> 

That's not the point. If everything looks good it should work good, 
regardless of which editor or tab-setting one's using.

> 
>>Of course, since I believe that tabs are always exactly 8 characters, I'd 
>>also be perfectly happy to just declare that anybody who disagrees with me 
>>is a moron and deserves to die (*).
> 
> 
> Seriously, you could always have it print warning messages but try to
> keep going by assuming 8 space tabs so that at least you can postpone
> fixing the problem until your current train of thought has pulled into
> the station.


There used to be $TABSIZE (or some such). Check it if you implement 
this. Or just skip it entirely. I would prefer the latter.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Get rid of .git/branches/ and .git/remotes/?

[linux]

> So, would this be considered legal or would it barf on baz?
> 
> foo		# No prefix
> 	bar	# tab prefix
>         baz     # 8 spaces prefix

It would barf on baz.  "\t" is not a prefix of "        ".

> Most people have tabsize at 8. Some don't. Some editors insert spaces
> instead of tabs while others don't. If we just match strings we'll
> end up with users sending bug-reports by cut'n pasting their perfectly
> valid-looking config which mixes tabs and spaces just because it's
> been edited by people using different editors.

> Real fun would be if the mta sends tabs as spaces. Then there'd
> be no way at all of telling if the config *is* valid or not.

We have this problem already with whitespace damage in the "before"
parts of patches.  Are you suggesting that the user will be confused
because some third party edited their config using an editor that
messed up the leading whitespace and then just left it broken?

There's a certain level of "evil gremlins came in during the night and
added bugs to my code" that I bloody well expect to be confusing!

You might have problems inserting a line that suffers mailer damage,
mailer sends you, but if you had sent it as a context diff, the patch
process would have choked on the whitespace anyway.

I'm not particularly agitating for an indent-based syntax, but it
is moderately popular and successful, and anyone criticising it should
at least know how it works.

The standard interpretation of leading whitespace accepts basically
that subset of "looks right" that is insensitive to tab setting.

> Excellent error messages aren't good enough. It's ok for Python, since 
> that's a programming language. We can expect infinitely more from 
> programmers than we can from users.

We're talking about git users here, right?
More specifically, we're talking about git users who are pulling from
multiple remote trees, no?

Perhaps you could clarify how this set of people is not a strict
subset of the set of programmers...

>> It irritates you the first few times until you learn to do it right in 
>> first place, just like it irritates most beginning C programmers that the
>> compiler keeps complaining about missing semicolons.

> If I'm trying out some new stuff that annoys me three times without me 
> seeing an obvious error on my part (in the editor of my choice) I 
> usually write it down as broken and move on.

What part of something like:
	Can't figure out nesting level on line 232.  Its leading
	whitespace ("        ", all spaces), is not a prefix or
	extension of the whitespace on the preceding line 230
	("\t", all tabs).
makes the error non-obvious?

If you refuse to read the error message at all, you can get confused,
but you'll also be confused by perfectly valid code producing diagnostics
like "error: dereferencing pointer to incomplete type" if you forget to
#include the right header 200 lines before the location of your error.

>> Computers will be annoying about syntax until they learn to do what
>> I want them to do rather than what I tell them to do, at which point
>> they'll be smart enough to start being annoying by doing what they want
>> to to instead of what I want them to do.

> That's not the point. If everything looks good it should work good, 
> regardless of which editor or tab-setting one's using.

Unfortunately, that's provably impossible, because it will look
different to different people.

Proof by example:

header1
    header2	# 4 spaces
        body3	# 8 spaces
	body4	# one tab

That looks good to me, with 8-space tabs:

header1 {
    header2 {
        body3
        body4
    }
}

But it also looks great to someone with 4-space tabs:

header1 {
    header2 {
        body3
    }
    body4
}

Too bad it doesn't work the same.

The standard whitespace-parsing algorithm rejects "body4" on the grounds
that it's ambiguous.  Simple, robust, and no making guesses that lead
to an error message 20 lines beyond the actual problem.  It just says
"Hey!  Fix line 4!"

>> Seriously, you could always have it print warning messages but try to
>> keep going by assuming 8 space tabs so that at least you can postpone
>> fixing the problem until your current train of thought has pulled into
>> the station.

> There used to be $TABSIZE (or some such). Check it if you implement 
> this. Or just skip it entirely. I would prefer the latter.

Fine with me.  It's a fallback heuristic anyway.

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

linux@horizon.com wrote:
>>So, would this be considered legal or would it barf on baz?
>>
>>foo		# No prefix
>>	bar	# tab prefix
>>        baz     # 8 spaces prefix
> 
> 
> It would barf on baz.  "\t" is not a prefix of "        ".
> 

But to the human eye they are the same. This is just a backwards way of 
making the computer think it's smart by recognizing a difference that, 
for all human purposes, aren't there. Like Linus said some posts ago; 
software should conform to humans. Not the other way around.

> 
>>Real fun would be if the mta sends tabs as spaces. Then there'd
>>be no way at all of telling if the config *is* valid or not.
> 
> 
> We have this problem already with whitespace damage in the "before"
> parts of patches.  Are you suggesting that the user will be confused
> because some third party edited their config using an editor that
> messed up the leading whitespace and then just left it broken?
> 

This is supposed to be edited by git config-set (or at least editable). 
When that breaks or when someone finds it inconvenient people will start 
using their editors. The logical way for a user to align new text to 
text 8 spaces away is to use the tab key. Depending on the editor (and 
the settings of that editor), the user will seem to have made perfectly 
correct changes that git will barf on, which brings us back to "software 
should conform to humans".

In short; This proposed format is just one step above a binary-format 
config file from the user-friendliness perspective.


> There's a certain level of "evil gremlins came in during the night and
> added bugs to my code" that I bloody well expect to be confusing!
> 

Can't help you there. I only do the cuddly mogwais.

> You might have problems inserting a line that suffers mailer damage,
> mailer sends you, but if you had sent it as a context diff, the patch
> process would have choked on the whitespace anyway.
> 

git only does unified diffs (but doesn't allow any fuzz, so it would 
break those too).

> I'm not particularly agitating for an indent-based syntax, but it
> is moderately popular and successful, and anyone criticising it should
> at least know how it works.
> 
> The standard interpretation of leading whitespace accepts basically
> that subset of "looks right" that is insensitive to tab setting.
> 
> 
>>Excellent error messages aren't good enough. It's ok for Python, since 
>>that's a programming language. We can expect infinitely more from 
>>programmers than we can from users.
> 
> 
> We're talking about git users here, right?
> More specifically, we're talking about git users who are pulling from
> multiple remote trees, no?
> 
> Perhaps you could clarify how this set of people is not a strict
> subset of the set of programmers...
> 

Package maintainers, tech-doc writers. Not really suits, but with a hint 
of tie nonetheless.

> 
>>That's not the point. If everything looks good it should work good, 
>>regardless of which editor or tab-setting one's using.
> 
> 
> Unfortunately, that's provably impossible, because it will look
> different to different people.
> 
> Proof by example:
> 
> header1
>     header2	# 4 spaces
>         body3	# 8 spaces
> 	body4	# one tab
> 
> That looks good to me, with 8-space tabs:
> 
> header1 {
>     header2 {
>         body3
>         body4
>     }
> }
> 
> But it also looks great to someone with 4-space tabs:
> 
> header1 {
>     header2 {
>         body3
>     }
>     body4
> }
> 
> Too bad it doesn't work the same.
> 
> The standard whitespace-parsing algorithm rejects "body4" on the grounds
> that it's ambiguous.


What I conclude from these examples are that;
1. Any brace-parsing algorithm does the right thing for every case.
2. Indentation-level parsing doesn't, so it's less robust.

Indentation-level parsing is nice-ish in a programming language because 
it enforces strong typing so others that read your program can easily do 
so. I personally disagree with that, but I can see the point.

How important is it that others can easily read your configuration file?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Get rid of .git/branches/ and .git/remotes/?

[Josef Weidendorfer]

On Monday 21 November 2005 00:26, Josef Weidendorfer wrote:
> On Sunday 20 November 2005 19:09, Linus Torvalds wrote:
> > 	[branches.origin]
> > 		url = master.kernel.org:/pub/scm/git/git.git
> > 		pull = master:origin
> 
> Two things:
> * base names are case insensitive. Repository shortcuts are case
> sensitive (and head names, too)
> * to get rid of .git/branches/XXX, XXX has to be allowed as
> base name. But XXX can contain anything a head name can (including ".").
> 
> Not really a problem. Use the ' for ' syntax:
> 
> [remotes]
> 	url = master.kernel.org:/pub/scm/git/git.git for origin
> 	pull = master:origin for origin
> 
> Not really nice. We can not have "for" as head name.

What about another syntax for multivalue vars?
Proposed syntax:

  [remote:origin]
    url = master.kernel.org:/pub/scm/git/git.git
    pull = master:origin

For this, the parser could return
    remote.url = master.kernel.org:/pub/scm/git/git.git for origin
    remote.pull = master:origin for origin

By introducing such a scheme, multi-value vars would fit perfectly
for use for .git/remotes or .git/branches.

Josef

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Tue, 22 Nov 2005, Josef Weidendorfer wrote:

>   [remote:origin]
>     url = master.kernel.org:/pub/scm/git/git.git
>     pull = master:origin
> 
> For this, the parser could return
>     remote.url = master.kernel.org:/pub/scm/git/git.git for origin
>     remote.pull = master:origin for origin
> 
> By introducing such a scheme, multi-value vars would fit perfectly
> for use for .git/remotes or .git/branches.

I don't know if you missed it, but hierarchical config keys were 
introduced by b17e659dd4007cb1d3eb5ac32b524c0c5ab59601:

[remote.origin]
	url = master.kernel.org:/pub/scm/git/git.git
	pull = master:origin

is parsable by

	git-config-set --get remote.origin.url

now.

Hth,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Nikolai Weibull]

Andreas Ericsson wrote:

> Excellent error messages aren't good enough. It's ok for Python, since
> that's a programming language. We can expect infinitely more from
> programmers than we can from users.

A semi-related question: who is the target audience of git?  I get the
feeling that most users will be programmers, so that's kind of a
non-argument (even though I agree with your standpoint).

Furthermore, does it really matter what format .git/config has now that
we have git-config-set?  Shouldn't all access go through that command,
so that we can change to some other format (YAML, XML, STUPIDABBR) if we
so desire without breaking anything?

Finally, a plain-text easy-to-edit format is great, and that's a good
enough argument not to use indentation (as has already been pointed out,
indentation is not always what it seems).

        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

Johannes Schindelin wrote:
> 
> 	git-config-set --get remote.origin.url
> 

So... "git-config-set" is used for both getting and setting? Why not 
just "git-config --set" and "git-config --get" to make things a bit less 
confusing?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Get rid of .git/branches/ and .git/remotes/?

[Adrien Beau]

On 11/22/05, Nikolai Weibull <mailing-lists.git@rawuncut.elitemail.org> wrote:
>
> who is the target audience of git?  I get the
> feeling that most users will be programmers, so that's kind of a
> non-argument (even though I agree with your standpoint).

If Git is successful, then there will also be a lot of bleeding-edge
users, people who want to be able to:

* Get the latest and greatest (and build it and run it)
* Browse the repository (with gitk or gitweb)
* Maybe (very occasionnally) create a simple patch

This is already the case with CVS, plenty of people know (or are
instructed to do) cvs checkout, cvs update, and nothing more. That's
not much, but they're CVS users, nevertheless.

Re: Get rid of .git/branches/ and .git/remotes/?

[Josef Weidendorfer]

On Tuesday 22 November 2005 18:56, Johannes Schindelin wrote:
> On Tue, 22 Nov 2005, Josef Weidendorfer wrote:
> >   [remote:origin]
> >     url = master.kernel.org:/pub/scm/git/git.git
> >     pull = master:origin

> I don't know if you missed it, but hierarchical config keys were 
> introduced by b17e659dd4007cb1d3eb5ac32b524c0c5ab59601:
> 
> [remote.origin]
> 	url = master.kernel.org:/pub/scm/git/git.git
> 	pull = master:origin

I know. My suggestion complements hierarchical keys:

 [myporcelain.headproperties: my/head.name]
    merge.candidates = my/other.head
    merge.default = your/master

would be the same as

 [myporcelain.headproperties]
    merge.candidates = my/other.head for my/head.name
    merge.default = your/master for my/head.name

It is about specifying the same " for "-part for multiple keys.
The idea is to use everything after a ":\s*" in a section name
to use as prefix for any " for "-part of keys values given in
this section.

Josef

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Wed, 23 Nov 2005, Josef Weidendorfer wrote:

> My suggestion complements hierarchical keys:
> 
>  [myporcelain.headproperties: my/head.name]
>     merge.candidates = my/other.head
>     merge.default = your/master
> 
> would be the same as
> 
>  [myporcelain.headproperties]
>     merge.candidates = my/other.head for my/head.name
>     merge.default = your/master for my/head.name

Okay. What about this config file?

-- snip --
	[myporcelain.headproperties: my/head.name]
		merge.candidates = my/other.head
	[myporcelain.headproperties]
		merge.candidates = blabla for my/head.name
-- snap --

I am not totally opposed to what you are trying, but I think it 
contradicts the KISS principle. (Note: the restriction that key names must
not start with a digit is also a contradiction to that.)

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Tue, 22 Nov 2005, Andreas Ericsson wrote:

> Johannes Schindelin wrote:
> > 
> > 	git-config-set --get remote.origin.url
> > 
> 
> So... "git-config-set" is used for both getting and setting? Why not just
> "git-config --set" and "git-config --get" to make things a bit less confusing?

I tried to do this more like a proof of a concept (Yeah, famous last 
words...) and tried to be not so intrusive. There is already a config.c, 
and to keep with the naming, this would have to move to config-lib.c to 
make space for config.c which really is the source for git-config$(X).

Should we rename config.c to config-lib.c, and config-set.c to config.c? 
Personally, I think it too intrusive, but what the heck.

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Josef Weidendorfer]

On Wednesday 23 November 2005 15:53, Johannes Schindelin wrote:
> Okay. What about this config file?
> 
> -- snip --
> 	[myporcelain.headproperties: my/head.name]
> 		merge.candidates = my/other.head
> 	[myporcelain.headproperties]
> 		merge.candidates = blabla for my/head.name
> -- snap --

I am not sure you want to show here. Your example gives

 myporcelain.headproperties.merge.candidates = my/other.head for my/head.name
 myporcelain.headproperties.merge.candidates = blabla for my/head.name

I.e. 2 values for the same variable with the same "for" specification.
This is perfectly valid.

Are you talking about the multiple representations for the same thing?
Then hierarchical config keys already introduce this:

 [myporcelain]
    headproperties.merge.candidates = blabla

is the same as

 [myprocelain.headproperties.merge]
    candidates = blabla
 
> I am not totally opposed to what you are trying, but I think it 
> contradicts the KISS principle.

This suggestion is about easier reading of config files; IMHO far easier
with some use cases; but yes, it is arguable if it's worth an added
complexity of config.c/config-set.c.

And of course this is no issue if config files are only to be written
by git-config-set. But I do not think this was the goal of the config
format.

Josef

> (Note: the restriction that key names must 
> not start with a digit is also a contradiction to that.)
> 
> Ciao,
> Dscho
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Wed, 23 Nov 2005, Josef Weidendorfer wrote:

>  [myporcelain]
>     headproperties.merge.candidates = blabla

With such a config file, git complains loudly. Key names are only allowed 
to be alphanumerical, and the first letter cannot even be a digit. No 
dots.

> This suggestion is about easier reading of config files; IMHO far easier
> with some use cases; but yes, it is arguable if it's worth an added
> complexity of config.c/config-set.c.

Well, I'll be glad to help the implementation of whatever we agree on.

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> So... "git-config-set" is used for both getting and setting? Why not just
>> "git-config --set" and "git-config --get" to make things a bit less confusing?
>
> I tried to do this more like a proof of a concept (Yeah, famous last 
> words...) and tried to be not so intrusive. There is already a config.c, 
> and to keep with the naming, this would have to move to config-lib.c to 
> make space for config.c which really is the source for git-config$(X).
>
> Should we rename config.c to config-lib.c, and config-set.c to config.c? 
> Personally, I think it too intrusive, but what the heck.

I do not think that change is intrusive.  We've renamed source
files number of times ;-).

I somehow get a very funny feeling to see "git-XXXX --get"
command that reports different things in different repositories
(for obvious reasons) called git-config, and not
git-repository-config.  But it probably is just me.

Anyway, the whole "remote specification in config file" is not a
very high priority for me right now.

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> I somehow get a very funny feeling to see "git-XXXX --get"
> command that reports different things in different repositories
> (for obvious reasons) called git-config, and not
> git-repository-config.  But it probably is just me.
> 

git-repo-config is way friendlier for us poor lazy folks. That last 'y' 
in "repository" really breaks the flow.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Thu, 24 Nov 2005, Andreas Ericsson wrote:

> git-repo-config is way friendlier for us poor lazy folks. That last 'y' in
> "repository" really breaks the flow.

How about "git-local-config"?

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 24 Nov 2005, Andreas Ericsson wrote:
> 
> 
>>git-repo-config is way friendlier for us poor lazy folks. That last 'y' in
>>"repository" really breaks the flow.
> 
> 
> How about "git-local-config"?
> 

Nah. It would really mess things up if there's ever such a thing as a 
real local config (ie, ~/.gitrc).

git-config-set handles configuration for a particular repo, so 
git-repo-config is better, IMO.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Get rid of .git/branches/ and .git/remotes/?

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> git-config-set handles configuration for a particular repo, so 
> git-repo-config is better, IMO.

Ok, so git-repo-config that is.  Johannes?

Re: Get rid of .git/branches/ and .git/remotes/?

[Petr Baudis]

Dear diary, on Sun, Nov 20, 2005 at 08:50:41PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > And I'm not 100% convinced that putting these branches in the config file 
> > has any real advantages over keeping them as separate files. Having 
> > everything in one place is nice, of course, and being able to copy just 
> > one file around might be convenient, but it _does_ make the config file 
> > more complicated.
> 
> And it _does_ make finding the information for less savvy git users more 
> easy.

Is that so?

I'm not 50% convinced, but if people are excited about it, I can live
with it; in that case I would like appropriately powerful
git-repo-config, though - so that I can say "list me all branch.*
section names". Surely I could play some ugly grep games, but ideally,
I would like to avoid peeking into the .git/config file directly
altogether in Cogito - call that proper layering. ;-)

> I'm not 100% convinced, either, but it could be a better concept than 
> different files in different places and different formats basically doing 
> the same.
> 
> But my thinking went like this: if Pasky and Junio can not agree on one 
> location and format, and therefore none of the two is deprecated, how 
> about giving them a way out they both might be able to agree to?

Now, those are just different concepts. Cogito's "branch" concept maps
single local head to a single remote head, 1:1. GIT's "remote" concept
maps (possibly not well-defined) bunch of local heads to a remote
repository (where they have same or different name) or a piece of it; to
accomplish this, it introduces a whole new rather complicated concept,
which nevertheless in part shares the namespace with heads (branches).

Surely, remotes are more flexible, but from the end-user perspective
they really act just as kind of "macros" compared to branches, except
that it's faster when you fetch multiple branches at once than when you
do it in sequence. I might add support for multibranch fetches to
Cogito, and I still intend to implement "readonly" remotes support for
the sake of compatibility with GIT, but I plan to stick to branches
otherwise. It's confusing enough to have remote and local heads, and
actually remotes make it even more confusing since you direct your
"direct touch" with the remote heads, now covered in some more abstract
entity.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Get rid of .git/branches/ and .git/remotes/?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>> But my thinking went like this: if Pasky and Junio can not agree on one 
>> location and format, and therefore none of the two is deprecated, how 
>> about giving them a way out they both might be able to agree to?
>
> Now, those are just different concepts. Cogito's "branch" concept maps
> single local head to a single remote head, 1:1. GIT's "remote" concept
> maps (possibly not well-defined) bunch of local heads to a remote
> repository (where they have same or different name) or a piece of it...

I agree.  They are simply different things and serve different
audiences.

When you are asked to pull from somebody else (and when you are
playing an integrator role, not an individual developer role,
you will be asked to pull from different people) you may not
want to immediately pull into your master branch.  I usually
either do "git checkout -b throwaway master" and pull into it,
or run "git fetch remote master:throwaway" followed by "git diff
master throwaway" to see what I'll be getting.  When you set up
one "remotes" file is when you realize that you are pulling this
way from the same place number of times, to reduce future
typing.  So as Pasky says, it is exactly "macro" and not "per
branch configuration".  It is just "per remote shorthand".

Cogito "branch" matches very naturally to what an individual
developer might want to do.  You have one branch that you use to
do your work tracking one upstream.  You can of course have more
than one upstream and branch, but the most typical usage would
be traditional CVS style setup to get updates from the central
location (described in branches/* file), fetch and merge from
there and push your changes back.  It is very well designed to
support this pattern of usage.

It may not make much sense for an integrator-role person to have
branches/master file to configure his "master" branch that
points at the URL of only one of his subsystem maintainers.  An
integrator-role person does not need "per branch" configuration
in that sense.  On the other hand "remotes" may help if the
integrator-role person regularly pulls from the same set of
subsystem maintainers.

Of course, an individual developer can set up a single remotes
file that describes the single upstream, fetching
"master:origin" and merging into his "master"; what "remotes"
file used that way does not give us, unlike "branch" of Cogito,
is that it does not say on which local branch that fetching and
merging happens.