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
general rule ends up being "he who writes the code gets to choose how it
gets done", because it turns out that there are a lot more people willing
to _argue_ about code than there are people willing to _write_ it, and
thus that "real code wins" rule actually works very well in practice.
I don't think I've ever really seen an argument where you ended up having
seriously competing patches. Yes, you can have patches to do things
different ways, but once you have that, it tends to be pretty easy for the
maintainer to just draw a line in the sand. And once one patch has been
accepted, it's all over.
So the real problem with "bike sheds" is actually when you have a culture
of arguing, and not enough of a culture of "just do it".
If you have a "just do it" culture, bike sheds are often good things. If
it really _is_ that easy, a bike shed is a perfect opportunity for
somebody who isn't all that deeply into a project to make a contribution
and start feeling more comfy about it. It obviously didn't happen here,
but it's definitely true that a lot of people in the kernel get introduced
to doing patches through various "trivial" things.
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 argue
about theoretical things (or about anything else, for that matter) more
than actually getting the damn job done.
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.
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 which
had what semantics. We could remove the old one entirely, of course (and
no, I don't remember which is which now either), and avoid that particular
problem, but it kind of soured me on it.
And if we truly have separate files, we should go all the way, and have
the good old "one file, one value" rule. Which we don't, and which I think
everybody admits would be horrible for this case for users (even if it
might be very nice for scripting).
Linus
-
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
