{"thread":{"id":"20538","subject":"RFC for 1.7: Do not checkout -b master origin/master on clone","startedAt":"2009-08-11T15:17:36Z","lastAt":"2009-08-17T17:45:05Z","messageCount":5,"participants":["Michael J Gruber","Santi Béjar","Junio C Hamano","Eric Wong","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"120279","messageId":"4A818B90.9050206@drmicha.warpmail.net","threadId":"20538","inReplyTo":null,"subject":"RFC for 1.7: Do not checkout -b master origin/master on clone","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-08-11T15:17:36Z","receivedAt":"2009-08-11T15:17:36Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"One common source of confusion for newcomers is the fact that master is\ngiven such a special treatment in git. While it is certainly okay and\nhelpful to set up a default branch in a new repository (git init) it is\nnot at all clear why it should be treated specially in any other\nsituation, such as:\n\n- Why is master the only local branch which git clone sets up (git\ncheckout -b master origin/master)?\n\n- Why does git svn set up a local branch with an svn upstream which is\ndetermined by latest svn commit at the time of the first git svn fetch?\n\nThis behaviour not only is hard to justify; in fact it gives users a\ncompletely wrong impression: by pretending that master is special, but\nalso by hiding core concepts (distinguishing local/remote branches,\ndetached heads) from the user at a point where that very hiding leads to\nconfusion.\n\nUnder the hood, it is of course HEAD which is given special treatment\n(and which in the majority of repos points to master), and git clone\nsets up a local branch according to HEAD (and does some other guess work\nwhen cloning bare repos), which means that git clone shows the same\n\"random\" behaviour which git svn clone does: Which local branch is set\nup by default depends on the current value of HEAD/most recent commit at\nthe time of the cloning operation.\n\nSo, I suggest that starting with git 1.7:\n\n- git clone does not set up any local branches at all\n- git svn fetch does not set up any local branches at all\n\nDucking under my desk...\nMichael\n"},{"id":"120306","messageId":"adf1fd3d0908111406w1ccae22fp3f26ecb89c67fa5e@mail.gmail.com","threadId":"20538","inReplyTo":"4A818B90.9050206@drmicha.warpmail.net","subject":"Re: RFC for 1.7: Do not checkout -b master origin/master on clone","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2009-08-11T21:06:02Z","receivedAt":"2009-08-11T21:06:02Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"2009/8/11 Michael J Gruber <git@drmicha.warpmail.net>:\n> One common source of confusion for newcomers is the fact that master is\n> given such a special treatment in git. While it is certainly okay and\n> helpful to set up a default branch in a new repository (git init) it is\n> not at all clear why it should be treated specially in any other\n> situation, such as:\n>\n> - Why is master the only local branch which git clone sets up (git\n> checkout -b master origin/master)?\n\nBecause master is the default branch in the remote repository?\n\n[...]\n\n> This behaviour not only is hard to justify; in fact it gives users a\n> completely wrong impression: by pretending that master is special,\n\nIt is not hard to justify (the git clone behavior). master is not\nspecial, it is just the default branch, but you can change it changing\nthe HEAD symlink.\n\n> but\n> also by hiding core concepts (distinguishing local/remote branches,\n> detached heads) from the user at a point where that very hiding leads to\n> confusion.\n>\n> Under the hood, it is of course HEAD which is given special treatment\n> (and which in the majority of repos points to master), and git clone\n> sets up a local branch according to HEAD (and does some other guess work\n> when cloning bare repos), which means that git clone shows the same\n> \"random\" behaviour which git svn clone does: Which local branch is set\n> up by default depends on the current value of HEAD/most recent commit at\n> the time of the cloning operation.\n\nIt's not random. And please don't mix the \"git clone\" and \"git svn\" case.\n\n> So, I suggest that starting with git 1.7:\n>\n> - git clone does not set up any local branches at all\n\nI think you should first think if this is going to really help\nnewcomers. I think this would be worst.\n\nInstead of \"why only 'master'?\" the question will be \"why I don't get\nany files in the workdir?\"\n\n\"git clone checks out the default branch, and this is 'master' by\ndefault\" is not that hard.\n\nHTH,\nSanti\n"},{"id":"120352","messageId":"7v8whpda2l.fsf@alter.siamese.dyndns.org","threadId":"20538","inReplyTo":"4A818B90.9050206@drmicha.warpmail.net","subject":"Re: RFC for 1.7: Do not checkout -b master origin/master on clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-12T02:45:22Z","receivedAt":"2009-08-12T02:45:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> One common source of confusion for newcomers is the fact that master is\n> given such a special treatment in git. While it is certainly okay and\n> helpful to set up a default branch in a new repository (git init) it is\n> not at all clear why it should be treated specially in any other\n> situation, such as:\n>\n> - Why is master the only local branch which git clone sets up (git\n> checkout -b master origin/master)?\n\nAs you know it is not strictly \"master\".  It is the primary branch at the\ncloned repository, which by convention is master\", but whatever remote end\npoints at with its HEAD.\n\nWe check out that primary branch to make it easy for people to work with\nthe simplest kind of CVS/SVN-like settings, which I suspect is 99% of\npeoples' projects.  Single \"trunk\" that is checked out immediately after\ncloning from a distribution point (read: a bare repository) ready to be\nused.\n\n> - Why does git svn set up a local branch with an svn upstream which is\n> determined by latest svn commit at the time of the first git svn fetch?\n\nI do not have comments on design decisions in git-svn, other than trusting\nthat Eric would exercise good design tastes to make things coherent with\nthe git native workflow when the consistency makes sense.\n\n> ..., and git clone\n> sets up a local branch according to HEAD (and does some other guess work\n> when cloning bare repos), which means that git clone shows the same\n> \"random\" behaviour...\n\nIt is because you are cloning from a repository that is used actively to\nbuild new history, flipping the HEAD left and right.  That is where the\nrandomness comes from.  IOW, a repository with an active work tree.\n\nIf you are cloning because you have your own private working area and you\nwould want to get another private working area to work simultaneously, you\nhave \"clone -n && checkout -t origin/whatever\".  Also if you are doing\nthis on a local machine (which is somewhat common), there is new-workdir\nscript in contrib/.  But this is _not_ the most common case we should\noptimize the usability of \"clone\" for.\n"},{"id":"120397","messageId":"20090812095656.GA7706@dcvr.yhbt.net","threadId":"20538","inReplyTo":"7v8whpda2l.fsf@alter.siamese.dyndns.org","subject":"Re: RFC for 1.7: Do not checkout -b master origin/master on clone","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-08-12T09:56:56Z","receivedAt":"2009-08-12T09:56:56Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano <gitster@pobox.com> wrote:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> > - Why does git svn set up a local branch with an svn upstream which is\n> > determined by latest svn commit at the time of the first git svn fetch?\n> \n> I do not have comments on design decisions in git-svn, other than trusting\n> that Eric would exercise good design tastes to make things coherent with\n> the git native workflow when the consistency makes sense.\n\nUsing 'trunk' (if available) as the master on new fetches does probably\nmake more sense based on the complaints I've gotten.  At the time,\nseveral projects I cared about did almost all their work in branches and\ntrunk would go untouched for months....  These days most projects I care\nabout are already using git :)\n\n-- \nEric Wong\n"},{"id":"120952","messageId":"vpqhbw6pc66.fsf@bauges.imag.fr","threadId":"20538","inReplyTo":"4A818B90.9050206@drmicha.warpmail.net","subject":"Re: RFC for 1.7: Do not checkout -b master origin/master on clone","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-17T17:45:05Z","receivedAt":"2009-08-17T17:45:05Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> - git clone does not set up any local branches at all\n> - git svn fetch does not set up any local branches at all\n\nIf you don't set up a local branch, it means either\n\n- You start with a detached HEAD, or\n- You start with no working tree at all.\n\nIn both cases, you introduce more trouble for the beginner, just more\nnotions to learn before being able to do the very first step.\n\nAnd you also break a good property of Git: in Git, you can use the\n\"one repo per branch\" or the \"multiple branches in a repository\" the\nway you want.\n\nPersonnally, I rarely have more than one branch for me (but I\nappreciate very much having one branch per developer). And this way, I\ncan just forget that Git has multiple branches in a repo. When I want\nto work on a project, I clone it, I hack, I commit, and then I\nsend the result (git push, git svn dcommit, git send-email, depending\non the project). In this workflow, I almost never have to use \"git\nbranch\", \"git checkout\", \"git merge\", it works, and Git does the right\nthing for me.\n\n-- \nMatthieu\n"}]}