On Mon, 8 May 2006, Junio C Hamano wrote: > > > > The problem with _that_ is that "git repo-config" can't add this kind of > > setup sanely: it doesn't understand that kind of statefulness. > > Wait a minute... Statefulness is not the issue, I think. Well, it does end up being.. > How would you tell your updated repo-config what to update and > what to look up? > > - I want the url for branch whose name is "origin" > > - I want to fetch their "for-linus" branch when fetching > from the branch whose name is "jgarzik" from now on. Exactly, git repo-config would have to know about this magic thing, and have a special argument like --state=branch.name that says that "state" is to be taken from the "branch.name" variable when seen. Then, in addition to the regexp, you would have a way to trigger on the "state" variable. > Now, how would that compare with: > > [branch.jgarzik] > url = git://git.kernel.org/... > fetch = for-linus > > or > [branch."JGarzik"] > url = git://git.kernel.org/... > fetch = for-linus It would be _able_ to do all the same things, but thanks to statefulness you'd be able to keep the section (and key) names the way they are. > On a related topic, I have always been torn about the "for" > convention. I agree. And I think it's actually very much the same thing. It adds state, but it adds it to each _value_, instead of adding it once "before" the values. 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