On Wed, 10 May 2006, Martin Langhoff wrote: > > Good one. I'm following this thread with interest, but it feels we've > been attacked by the 'bike shed bug' in the act of redesigning > Windows.ini. 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. > 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. 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 - : 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