Jakub Narebski <jnareb@xxxxxxxxx> writes: > Well, the question is if git-clone would generate appropriate config > entries in addition to or instead of $GIT_DIR/remotes/origin file... What I meant by "irrelevant" is that it is purely syntax. I would rather nail down the desired semantics first, and then worry about the syntax. We have done remotes/origin file by default and allowed the same thing specified in configuration file for people who prefer configuration file, and I do not see an immediate need to change that. Only if/when the desired semantics turns out to be too complex to be expressed in the remotes/ file scheme and at the same time if configuration file is easier to express the same information, we should start talking about favoring configuration file over remotes/ file, and perhaps generating the config entries by default without generating remotes/. In either case, I do not think generating _both_ by default is a bad idea. They will become out of sync and the user either need to delete one or the other to avoid confusion. > By the way, what do you think about extended refspec syntax, namely > in addition to <remote name>:<local name> it would allow to say > <remote name>:<local name>:<local branch to merge into>? I do not think it is reasonable to assume that one remote branch is to be always merged into one fixed local branch, so that is too limiting as an extension. In the configuration file, I think we already allow the default remote to be fetched from and remote branches to be merged per branch statically. A reasonable thing to do is to see how satisfied users are with that facility, what they find missing there. Worrying about the syntax should wait until we know what kind of things need to be expressed; that can be done both by extending the existing configuration and/or introducing a new entries in remotes/ files but the point is that is mere implementation detail. - To unsubscribe from this list: 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