Re: Implementing branch attributes in git config

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 10, 2006, 23:17 UTC
Message-ID: <46a038f90605101617x1aa9bd2du959ead77ebf61795@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0605100823350.3718@g5.osdl.org>

On 5/11/06, Linus Torvalds <torvalds@osdl.org> wrote:

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

Show 13 quoted lines

> > As an end-user, I have personally stayed away from the increasingly
> > 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
> .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
> 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