On 5/11/06, Linus Torvalds <torvalds@xxxxxxxx> 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.
> 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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html