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

linux@horizon.com wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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