On 5/11/06, Linus Torvalds  wrote:

quoted text
> Sure. It clearly _is_ a bike shed, which is why I posted patches: I think

> the way to resolve bike sheds is to "just do it". In the kernel, the

there's no disputing that!
> So don't knock the bike sheds. It's a BSD term, and I think there's a

quoted text
> _reason_ why it's a BSD term. Those people seem to sometimes like to

Apologies -- I didn't want to know it, but I do wonder what the gain

behind the change is. It seems to me that it would be a bad idea to

store refs in the config file and, in my mind at least, branch info is

closer to refs.
> > As an end-user, I have personally stayed away from the increasingly

quoted text
> > complex scheme for remotes waiting for it to settle, and stuck with

> > the old-styled .git/branches stuff which is slam-dunk simple and it

> > just works.

>

> It does work, and I think it's nice in many ways. It was certainly a good

> way to prototype things.

>

> At the same time, especially with moving things more to C (or almost any

> other language, for that matter - shell is really pretty special in making

> it _easier_ to have things in individual files), it's in many ways nicer

> to have a more structured representation that has a nice fixed interface

> and a library and known access methods behind it.

But it is a bit of a loss for perl/shell porcelains, and for users

that abuse the contents of .git directly on a regular basis...
there's nothing to stop us from having a structured representation of

what's in .git/branches/
> And I'm personally actually pretty fed up with the .git/branches/ and

quoted text
> .git/remotes/ thing, partly because I can never remember which file is

> which. I had to look at the code of git-parse-remote.sh to remind me

Agreed, it's a mess, but I suspect it's still there to support cogito.

In keeping with the 'talk code' ethos, I'll work on adding support for

.git/remotes in cogito.
> And if we truly have separate files, we should go all the way, and have

quoted text
> the good old "one file, one value" rule.

What about one semantics, one file? So far we have had 3 semantics:

git config, remotes, refs. And git config has been mostly

project-indepentent. In fact, I have been copying it across my

checkouts of different, unrelated projects. You just don't do that

with remotes or refs.
cheers,
martin

-

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