John Medema <john.medema@xxxxxxxxxxxxxxx> writes: > Option D has the downside that it changes the behavior of more code > (cmdline and gui), which is why I didn't suggest it before. It also > has the downside of making the branch list longer. But that's the > nature of cloning; if I copy a full directory of files to a new > directory I expect to get a full set of files. You shouldn't be too literal with the word "clone". The reason people "clone" a project often is to work on their own thing, which may be based only on a handful of branches the upstream publishes. So I do necessarily buy "But that's the nature" argument myself. Not doing your option D has another benefit, other than "smaller number of branches" you mentioned, and it is more important one in practice. Once you start your own development with your own set of branches, you want to see the names of _your_ branches in your repository, not mixed with 47 other uninteresting branches your upstream has for its purpose. Whey you are working on fixing something for the maintenance track of the upstream, you do want to see your 'fix-that-thing' local branch forked from 'maint' branch of the upstream, and you may or may not also want to see a copy of 'maint' branch in your local branch namespace, but you certainly do not want to see 'master', 'next', 'pu' and all the topic branches the upstream uses to build and advance these branches ahead of 'maint' that you are currently focusing on. In fact, with ancient versions of Git, you got copies of all branches your upstream has as your local branches. This turned to be unusable and was corrected at around v1.5.0 release---this was done primarily so that we can have a sane remote-tracking, but uncluttering the local branch space was also a reason why we transitioned to the current "separate remote" layout. -- 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