Linus Torvalds wrote: > 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. [...] >> 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. > 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). On one hand the remotes/ (or older branches/) is similar to refs/heads and refs/tags that it contains shortcut names for pulling and pushing. On the other hand configuration should belong to configuration. Besides, AFAICT we did not have the place to have branch specific configuration (like description, default place to pull from + marking branch as immutable, default place to push to, etc.) and if I understand correctly branches/ was used for something else. refs/heads/`name` stored branches, including temporary branches which did not need configuration. I guess that for the time being we can have remotes both in remotes/ and in config file, plus script to freely transform between them (unless some config would be unattainable by remotes/ file). -- Jakub Narebski Warsaw, Poland - : 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