Sean <seanlkml@xxxxxxxxxxxx> writes: > I think your Nack was a little rash here. The feature would be quite > useful to work flows other than yours. It sounds like what _you_ want > is a feature to select branches when cloning rather than the current > default of cloning all. That would stop your developers having to > delete branches and editing .git/remotes/origin immediately > after cloning. I think this conversation demonstrates that this previous statement of yours was also rather rash: The essential point is that most of the time the Git user should not have to manually create the merge entries in the config file. Git should be smart enough to get it right most of the time automatically. There is no "get it right most of the time" that would apply to every workflow. We should just admit that no default layout and configuration would suit everybody's needs. What we should do is to try to capture a handful useful patterns and make it easy for people to apply those canned patterns. For example, that is what we did for "git clone". We identified two common layouts, traditional and separate-remote, and we support both. The reason we might want to favor separate-remote over traditional should be based on the expected workflow and expertise level of the majority of users. If a census turns out that the more experienced people tend to prefer traditional layout, then changing the default to separate-remote would be easier even if people with workflow separate-remote is more appropriate is not the absolute majority, because the layout can be easily changed by more experienced folks. I think the "what should the default merge source be" topic is very similar. There is no single _right_ way and to some extent what the vanilla default is does not really matter. - 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