Junio, I can appreciate the amount of clutter you'd get with the ancient behavior. That said, I'd be willing to live with it. I personally prefer to see all the branches coming and going - if the branches are good enough for upstream, they're good enough for me (I'm really good an ignoring stuff). Realizing I'm probably not in the majority, I'd think that re-enabling this ancient behavior as a non-default option (like git config push.default) might be nice for those of my inclination. As of now I need to write a script to do a fetch + create_branch( diff( local vs origin ) ). But like I said before, I was hoping I'd have an easier time convincing you guys on Options A or B to make the gui more consistent with the cmdline. Thanks, John Medema Systems Administrator United Drugs, a Subsidiary of AAP (American Associated Pharmacies) john.medema@xxxxxxxxxxxxxxx 7243 N 16th Street, Phoenix, AZ 85020 Office: 602-678-1179 x126 Fax: 602-639-4631 On Fri, Sep 4, 2015 at 3:16 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. -- HIPAA NOTICE: It is against United Drugs’ policy to receive or send un-encrypted or non-secured email correspondence containing Protected Health Information (PHI) as defined by HIPAA law. Please use fax or phone for correspondence containing PHI. -- This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, contact the sender by reply email, and destroy all copies of the original message. -- 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