On Sat, 6 May 2006, sean wrote: > > Okay, I mistook the scope of you comments to apply to all of git rather than > as a reminder that we can't forget about the toolkit design. So I take it > you're not at all against git including higher level user commands; just so > long as they're built on top of lower level toolkit commands that other > porcelain can use as well. Correct. I think we've been able to handle that balance particularly well so far. Or maybe the porcelains don't complain enough. > In this particular case I see "git repo-config" as the low level command that > any porcelain can use to access the remotes information and the proposed > "git remotes" as a simple convenience wrapper on top of this. Of course, > everyone has to agree on the config file format; but that is true whether > the human-friendly wrapper exists or not. I agree, but my point is that in order for a porcelain to _use_ "repo-config", the config file format needs to be defined somewhere, and we need to tell people that it's not changing. Are we there yet? That was my argument for why we should concentrate not on what the user wrapper should be named, but why we should look at what the low-level meaning of these things are. Finally, I think "git repo-config" is buggy. Try with this .config file: [user] name = Bozo the Clown email = bozo@xxxxxxxxxx [core] filemode = true [merge] summary = true and then do git repo-config core.gitproxy 'dummy example' and look where it ends up. For me, it ends up at the end, in the "[merge]" section, which is obviously bogus. So we'd really be screwing with porcelain if we made them use this ;) 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