{"thread":{"id":"29464","subject":"Bug: \"git checkout -b\" should be allowed in empty repo","startedAt":"2012-01-29T06:09:11Z","lastAt":"2012-02-07T08:04:11Z","messageCount":34,"participants":["Michael Haggerty","Junio C Hamano","Jeff King","Johannes Sixt","Jakub Narebski","demerphq","Andrew Ardill"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183244","messageId":"4F24E287.3040302@alum.mit.edu","threadId":"29464","inReplyTo":null,"subject":"Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-01-29T06:09:11Z","receivedAt":"2012-01-29T06:09:11Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"When starting a new repo, git seems to insist that the first commit be\nmade on a branch named \"master\":\n\n $ git --version\n git version 1.7.9\n $ git init git-test\n Initialized empty Git repository in /home/mhagger/tmp/git-test/.git/\n $ cd git-test\n $ git checkout -b foo\n fatal: You are on a branch yet to be born\n\nI would call this a bug; the last command should be allowed. The\nplumbing allows it:\n\n $ git symbolic-ref HEAD refs/heads/foo\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"183247","messageId":"7vwr8bvvxj.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"4F24E287.3040302@alum.mit.edu","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-29T06:56:24Z","receivedAt":"2012-01-29T06:56:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> When starting a new repo, git seems to insist that the first commit be\n> made on a branch named \"master\":\n>\n> $ git --version\n> git version 1.7.9\n> $ git init git-test\n> Initialized empty Git repository in /home/mhagger/tmp/git-test/.git/\n> $ cd git-test\n> $ git checkout -b foo\n> fatal: You are on a branch yet to be born\n>\n> I would call this a bug; the last command should be allowed. The\n> plumbing allows it:\n>\n> $ git symbolic-ref HEAD refs/heads/foo\n\nYour last sentence is nonsense. The plumbing equivalent of that command\nis *not* what you wrote above, but is more like [*1*]:\n\n\tgit update-ref refs/heads/foo $(git rev-parse --verify HEAD) &&\n git symbolic-ref HEAD refs/heads/foo\n\nAnd the first step will fail the same way. While I share the sense of\nannoyance with you, I do not think that it is a bug in \"checkout -b\".\n\nWhen you are on an unborn branch, what the \"symbolic-ref HEAD\" command\nreports does *not* appear in the output from the \"for-each-ref refs/heads\"\ncommand (similarly, that branch name does not appear in the output from\nthe \"git branch\" command).\n\nSuch a behaviour indeed is *curious* and very *different* from the normal\ncase of being on an existing branch, but is that a bug?\n\nYou need to first admit that the state immediately after \"git init\" (or\nfor that matter, \"checkout --orphan\") where you are on an unborn branch\n*is* special. Some things that would normally make sense would not.\n\n\n[Footnote]\n\n*1* Because you are not switching to a different commit, there won't be a\nneed for the third step which is \"git read-tree -m -u HEAD@{1} HEAD\" that\nwould usually be necessary if you are giving a starting commit that is\ndifferent from HEAD.\n"},{"id":"183248","messageId":"7vsjizvtfo.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"7vwr8bvvxj.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-29T07:50:19Z","receivedAt":"2012-01-29T07:50:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> ...\n> Such a behaviour indeed is *curious* and very *different* from the normal\n> case of being on an existing branch, but is that a bug?\n>\n> You need to first admit that the state immediately after \"git init\" (or\n> for that matter, \"checkout --orphan\") where you are on an unborn branch\n> *is* special. Some things that would normally make sense would not.\n\n[sorry for having sent an incomplete message without conclusion]\n\nThe question then becomes this: what do you want to do about it with this\nspecific case, and more importantly what do you want to do about other\ncommands and options that would not make sense when HEAD knows what branch\nthe user wants to put the first commit on but there is no commit yet?\n\nFor some commands, we _do_ try to come up with a special case codepath so\nthat a command issued in the unborn state mimics the behaviour of the\ncommand issued in the normal case to various different degrees. \"git pull\"\ninto an unborn branch simply resets to the other branch, for example, and\nwhile technically speaking that is not merging the other branch into the\ncurrent commit (which does not exist), we do so because it was deemed to\nbe the most sensible behaviour to parallel the normal case.\n\nI am not sure \"git checkout -b foo\" (without explict HEAD [*1*]) should\nspecial case and degenerate to \"symbolic-ref HEAD refs/heads/foo\" when\nHEAD points to a nonexistent branch. The mimicking does not go far enough\nto satisfy people who are pedantic enough to expect \"git checkout -b foo\"\nto work when you haven't even instantiated your current branch (when you\nare on an already instantiated branch, after \"git checkout -b foo\", \"git\nbranch\" output will show both foo and the branch you were on, but if you\nstart from an unborn branch, the behaviour will be different and a pedant\nwill notice the difference).\n\nIt may make sense to let\n\n $ git branch -m trunk\n\nor even\n\n $ git branch -m master trunk\n\nmove away from an unborn \"master'\"after \"git init\", with a special case\ncodepath. When you start from an instanticated branch, after a successful\nsuch renaming, the original branch will not exist, and the new branch will\nexist. This property would also hold true if you start from an unborn one,\nso it would be much better mimickery than \"git checkout -b foo\" case you\nbrought up in this thread.\n\n\n[Footnote]\n\n*1* Given HEAD or $(git symbolic-ref HEAD) as the starting commit\nexplicitly, the command should error out.\n"},{"id":"183286","messageId":"4F263AEE.4080409@alum.mit.edu","threadId":"29464","inReplyTo":"7vwr8bvvxj.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-01-30T06:38:38Z","receivedAt":"2012-01-30T06:38:38Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 01/29/2012 07:56 AM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n> \n>> When starting a new repo, git seems to insist that the first commit be\n>> made on a branch named \"master\":\n>>\n>> $ git --version\n>> git version 1.7.9\n>> $ git init git-test\n>> Initialized empty Git repository in /home/mhagger/tmp/git-test/.git/\n>> $ cd git-test\n>> $ git checkout -b foo\n>> fatal: You are on a branch yet to be born\n>>\n>> I would call this a bug; the last command should be allowed. The\n>> plumbing allows it:\n>>\n>> $ git symbolic-ref HEAD refs/heads/foo\n> \n> Your last sentence is nonsense. The plumbing equivalent of that command\n> is *not* what you wrote above, but is more like [*1*]:\n> \n> \tgit update-ref refs/heads/foo $(git rev-parse --verify HEAD) &&\n> git symbolic-ref HEAD refs/heads/foo\n\nAll that I meant is that the one command is the equivalent of *what the\nuser wants and expects* in the *particular* situation that I described\n[1]. I should have been clearer.\n\n> And the first step will fail the same way. While I share the sense of\n> annoyance with you, I do not think that it is a bug in \"checkout -b\".\n> \n> When you are on an unborn branch, what the \"symbolic-ref HEAD\" command\n> reports does *not* appear in the output from the \"for-each-ref refs/heads\"\n> command (similarly, that branch name does not appear in the output from\n> the \"git branch\" command).\n> \n> Such a behaviour indeed is *curious* and very *different* from the normal\n> case of being on an existing branch, but is that a bug?\n\nWhen git behaves differently than a typical user would expect for no\ngood reason, that is a bug (albeit a UI bug). The fact that somebody\nwho knows the internals of git can find an excuse for the inconsistency\nmight be an explanation for how the bug arose but it doesn't make it\nless of a bug.\n\n> You need to first admit that the state immediately after \"git init\" (or\n> for that matter, \"checkout --orphan\") where you are on an unborn branch\n> *is* special. Some things that would normally make sense would not.\n\nISTM that this state is more special than it needs to be due to an\ndesign flaw of git [2]. But even given the fact that this case is\nspecial *internal* to git, there is no reason to let that specialness\nleak out to the user more than necessary.\n\n> [...]\n> I am not sure \"git checkout -b foo\" (without explict HEAD [*1*]) should\n> special case and degenerate to \"symbolic-ref HEAD refs/heads/foo\" when\n> HEAD points to a nonexistent branch. The mimicking does not go far enough\n> to satisfy people who are pedantic enough to expect \"git checkout -b foo\"\n> to work when you haven't even instantiated your current branch (when you\n> are on an already instantiated branch, after \"git checkout -b foo\", \"git\n> branch\" output will show both foo and the branch you were on, but if you\n> start from an unborn branch, the behaviour will be different and a pedant\n> will notice the difference).\n\nFor me, \"git checkout -b foo\" means \"leave the old branch in its current\nstate and move to a new branch that is in the same state.\" If the old\nbranch was unborn, then it should remain unborn after the command, and I\nshould be moved to a new unborn branch. Since an unborn branch in git\nis not a branch, I would have no expectation that the old branch exists\nafter the command [3].\n\n> It may make sense to let\n> \n> $ git branch -m trunk\n> \n> or even\n> \n> $ git branch -m master trunk\n> \n> move away from an unborn \"master'\"after \"git init\", with a special case\n> codepath. When you start from an instanticated branch, after a successful\n> such renaming, the original branch will not exist, and the new branch will\n> exist. This property would also hold true if you start from an unborn one,\n> so it would be much better mimickery than \"git checkout -b foo\" case you\n> brought up in this thread.\n\nIt makes sense that \"git branch -m\" can *also* be used to escape an\nunborn master, but this command won't necessarily occur to people\naccustomed to using \"git checkout -b\" for creating new branches.\n\nMichael\n\n[1] Of course, here \"the user\" means me :-) but I predict that other\nusers would feel the same.\n\n[2] Namely that \"orphan\" commits have no parents, instead of having an\n\"empty repository\" commit (something like \"000000*\") as parent. By\ncontrast, when a new Subversion repository is created, it automatically\ngets a pseudo \"r0\" commit that represents the empty repository. The r0\ncommit can be used in the UI most places that a \"real\" commit can be\nused. If the 0000000 commit could be used in the same way in git, it\nwould remove a lot of special casing. For example, an \"unborn branch\"\ncould be initialized pointing at 0000000. Even if there is some deeper\nreason why such a design wouldn't have worked, perhaps such a concept\ncould be faked for the user interface.\n\n[3] If commit 0000000 were treated specially, then there would be no\nunborn branches but only branches pointing at the empty commit. In that\ncase, my expectation would change--the old branch should be left\npointing at 0000000. But currently git has no concept of an unborn\nbranch that is not HEAD.\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"183356","messageId":"7v39axc9gp.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"4F263AEE.4080409@alum.mit.edu","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-30T18:48:54Z","receivedAt":"2012-01-30T18:48:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> [3] If commit 0000000 were treated specially, then there would be no\n> unborn branches but only branches pointing at the empty commit. In that\n> case, my expectation would change--the old branch should be left\n> pointing at 0000000. But currently git has no concept of an unborn\n> branch that is not HEAD.\n\nAnd it probably is not a good thing to add such. Under that constraints,\nHEAD that says refs/heads/foo where foo does not exist yet needs to be\nspecial cased at places where it matters.\n\nFor that matter, even if we artificially created refs/heads/foo before any\ncommit is made and made it point at 0{40}, you would need to add special\ncases to other parts of the system (e.g. \"commit\" needs to notice that the\nresult should be a root, not a child of 0{40}; \"checkout other_branch\"\nneeds to notice that it should refrain from running the equivalent of\n\"read-tree -m HEAD other_branch\" because HEAD does not point at a real\ntree; etc.), so it does not change the fact that the unborn branch is case\nis special.\n\nNote that I am not saying that we shouldn't add support for special cases\nwith special case codepaths.\n\nPerhaps we would need to sprinkle more special case magic like this (this\nis for the special case that arises from the same cause)?\n\n builtin/branch.c | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 7095718..0997e75 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -640,6 +640,13 @@ static int edit_branch_description(const char *branch_name)\n \tstruct strbuf buf = STRBUF_INIT;\n \tstruct strbuf name = STRBUF_INIT;\n \n+\tstrbuf_addf(&name, \"refs/heads/%s\", branch_name);\n+\tif (!ref_exists(name.buf)) {\n+\t\tstrbuf_reset(&name);\n+\t\treturn error(\"No such branch '%s'.\", branch_name);\n+\t}\n+\tstrbuf_reset(&name);\n+\n \tread_branch_desc(&buf, branch_name);\n \tif (!buf.len || buf.buf[buf.len-1] != '\\n')\n \t\tstrbuf_addch(&buf, '\\n');\n"},{"id":"183378","messageId":"7vaa55ar4v.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"7v39axc9gp.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-30T20:10:08Z","receivedAt":"2012-01-30T20:10:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Note that I am not saying that we shouldn't add support for special cases\n> with special case codepaths.\n>\n> Perhaps we would need to sprinkle more special case magic like this (this\n> is for the special case that arises from the same cause)?\n> ...\n\nAnd the special case for \"checkout -b\" may look like this.\n\nThe early part of switch_branches() that computes old is probably be\nbetter moved to the caller cmd_checkout() and used in the new code that\ndetects the \"unborn\" case, and passed as to switch_branches() as the third\nparameter. Such improvements, adding tests and pleasant commit log\nmessage is left as an exercise for the interested and motivated, as usual\n;-)\n\n\n\n builtin/checkout.c | 24 ++++++++++++++++++++++++\n 1 files changed, 24 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex f1984d9..195c40b 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -922,6 +922,19 @@ static int parse_branchname_arg(int argc, const char **argv,\n \treturn argcount;\n }\n \n+static int switch_unborn_to_new_branch(struct checkout_opts *opts, const char *old_ref)\n+{\n+\tint status;\n+\tstruct strbuf branch_ref = STRBUF_INIT;\n+\n+\tstrbuf_addf(&branch_ref, \"refs/heads/%s\", opts->new_branch);\n+\twarning(_(\"Leaving the unborn branch '%s' behind...\"),\n+\t\tskip_prefix(old_ref, \"refs/heads/\"));\n+\tstatus = create_symref(\"HEAD\", branch_ref.buf, \"checkout -b\");\n+\tstrbuf_reset(&branch_ref);\n+\treturn status;\n+}\n+\n int cmd_checkout(int argc, const char **argv, const char *prefix)\n {\n \tstruct checkout_opts opts;\n@@ -1093,5 +1106,16 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \tif (opts.writeout_stage)\n \t\tdie(_(\"--ours/--theirs is incompatible with switching branches.\"));\n \n+\tif (!new.commit) {\n+\t\tunsigned char rev[20];\n+\t\tint flag, status;\n+\t\tchar *old_ref = resolve_refdup(\"HEAD\", rev, 0, &flag);\n+\n+\t\tif ((flag & REF_ISSYMREF) && is_null_sha1(rev)) {\n+\t\t\tstatus = switch_unborn_to_new_branch(&opts, old_ref);\n+\t\t\tfree(old_ref);\n+\t\t\treturn status;\n+\t\t}\n+\t}\n \treturn switch_branches(&opts, &new);\n }\n"},{"id":"183393","messageId":"20120130214842.GA16149@sigill.intra.peff.net","threadId":"29464","inReplyTo":"7v39axc9gp.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-30T21:48:43Z","receivedAt":"2012-01-30T21:48:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 30, 2012 at 10:48:54AM -0800, Junio C Hamano wrote:\n\n> Note that I am not saying that we shouldn't add support for special cases\n> with special case codepaths.\n> \n> Perhaps we would need to sprinkle more special case magic like this (this\n> is for the special case that arises from the same cause)?\n\nI like your patch better than trying to pass around \"0{40}\", but:\n\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index 7095718..0997e75 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -640,6 +640,13 @@ static int edit_branch_description(const char *branch_name)\n> \tstruct strbuf buf = STRBUF_INIT;\n> \tstruct strbuf name = STRBUF_INIT;\n> \n> +\tstrbuf_addf(&name, \"refs/heads/%s\", branch_name);\n> +\tif (!ref_exists(name.buf)) {\n> +\t\tstrbuf_reset(&name);\n> +\t\treturn error(\"No such branch '%s'.\", branch_name);\n> +\t}\n> +\tstrbuf_reset(&name);\n> +\n\nI wonder if this conditional should have:\n\n unsigned char sha1[20];\n const char *head_points_at = resolve_ref_unsafe(\"HEAD\", sha1, 1, NULL);\n if (!head_points_at || strcmp(head_points_at, name.buf))\n return error(\"No such branch '%s'.\", branch_name);\n\nto special-case unborn branches that we are actually pointing to.\n\nIOW, the problem with the current code is that it allows typos and other\narbitrary bogus names to be silently described, even though doing so is\nprobably an error. But since this branch is already in use (even though\nits ref does not technically exist yet), it's probably not an error.\n\nAs an aside, the strbuf_reset inside the conditional should be\nstrbuf_release, no? Otherwise we are leaking. And probably the one\noutside, too. Even though we release the memory later, there are error\ncode-paths that do not. (And yes, I know this was a quick sketch and not\na real patch, but I wanted to point it out in case it turns into a real\none).\n\n-Peff\n"},{"id":"183394","messageId":"20120130215043.GB16149@sigill.intra.peff.net","threadId":"29464","inReplyTo":"7vaa55ar4v.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-30T21:50:43Z","receivedAt":"2012-01-30T21:50:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 30, 2012 at 12:10:08PM -0800, Junio C Hamano wrote:\n\n> diff --git a/builtin/checkout.c b/builtin/checkout.c\n> index f1984d9..195c40b 100644\n> --- a/builtin/checkout.c\n> +++ b/builtin/checkout.c\n> @@ -922,6 +922,19 @@ static int parse_branchname_arg(int argc, const char **argv,\n> \treturn argcount;\n> }\n> \n> +static int switch_unborn_to_new_branch(struct checkout_opts *opts, const char *old_ref)\n> +{\n> +\tint status;\n> +\tstruct strbuf branch_ref = STRBUF_INIT;\n> +\n> +\tstrbuf_addf(&branch_ref, \"refs/heads/%s\", opts->new_branch);\n> +\twarning(_(\"Leaving the unborn branch '%s' behind...\"),\n> +\t\tskip_prefix(old_ref, \"refs/heads/\"));\n> +\tstatus = create_symref(\"HEAD\", branch_ref.buf, \"checkout -b\");\n> +\tstrbuf_reset(&branch_ref);\n> +\treturn status;\n> +}\n\nIs it really worth warning? After all, by definition you are not leaving\nany commits or useful work behind.\n\nAlso, this has the same strbuf reset/release leak as the last patch. :)\n\n-Peff\n"},{"id":"183407","messageId":"4F27ACED.2050709@alum.mit.edu","threadId":"29464","inReplyTo":"7v39axc9gp.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-01-31T08:57:17Z","receivedAt":"2012-01-31T08:57:17Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 01/30/2012 07:48 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n> \n>> [3] If commit 0000000 were treated specially, then there would be no\n>> unborn branches but only branches pointing at the empty commit. In that\n>> case, my expectation would change--the old branch should be left\n>> pointing at 0000000. But currently git has no concept of an unborn\n>> branch that is not HEAD.\n> \n> And it probably is not a good thing to add such. Under that constraints,\n> HEAD that says refs/heads/foo where foo does not exist yet needs to be\n> special cased at places where it matters.\n> \n> For that matter, even if we artificially created refs/heads/foo before any\n> commit is made and made it point at 0{40}, you would need to add special\n> cases to other parts of the system\n\nNo, the idea is to avoid special casing by making 0{40} into a real (but\nempty) revision.\n\n> (e.g. \"commit\" needs to notice that the\n> result should be a root, not a child of 0{40};\n\nNo, commits that were previously generated as orphans *would* now be\ngenerated as children of the special 0{40} commit.\n\n> \"checkout other_branch\"\n> needs to notice that it should refrain from running the equivalent of\n> \"read-tree -m HEAD other_branch\" because HEAD does not point at a real\n> tree;\n\nNo, it would merge the 0{40} commit with other_branch like usual,\nresulting in the same contents as other_branch. Indeed, if other_branch\nis also ultimately a descendant of 0{40}, this would be like a\nfast-forward merge.\n\n> etc.\n\nThis \"etc\" might include problems.\n\n> so it does not change the fact that the unborn branch is case\n> is special.\n\nOn the contrary, I believe that much special casing could be eliminated\nand the UI made more uniform by treating everything as a descendant of a\nspecial \"NULL\" commit.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"183408","messageId":"4F27BBED.9080902@viscovery.net","threadId":"29464","inReplyTo":"4F27ACED.2050709@alum.mit.edu","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-01-31T10:01:17Z","receivedAt":"2012-01-31T10:01:17Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 1/31/2012 9:57, schrieb Michael Haggerty:\n> No, the idea is to avoid special casing by making 0{40} into a real (but\n> empty) revision.\n\nBut then why not just have git init perform the equivalent of\n\n c=$(echo \"Start\" | git commit-tree $empty_tree_sha1) &&\n git update-ref refs/heads/master $c\n\nPeople who dislike an empty initial commit can always use \"git commit\n--amend\" for the first \"real\" commit.\n\n-- Hannes\n"},{"id":"183409","messageId":"m3k448che9.fsf@localhost.localdomain","threadId":"29464","inReplyTo":"4F27ACED.2050709@alum.mit.edu","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-01-31T10:09:18Z","receivedAt":"2012-01-31T10:09:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael Haggerty writes:\n> On 01/30/2012 07:48 PM, Junio C Hamano wrote:\n>> Michael Haggerty writes:\n>> \n>>> [3] If commit 0000000 were treated specially, then there would be no\n>>> unborn branches but only branches pointing at the empty commit. In that\n>>> case, my expectation would change--the old branch should be left\n>>> pointing at 0000000. But currently git has no concept of an unborn\n>>> branch that is not HEAD.\n>> \n>> And it probably is not a good thing to add such. Under that constraints,\n>> HEAD that says refs/heads/foo where foo does not exist yet needs to be\n>> special cased at places where it matters.\n>> \n>> For that matter, even if we artificially created refs/heads/foo before any\n>> commit is made and made it point at 0{40}, you would need to add special\n>> cases to other parts of the system\n> \n> No, the idea is to avoid special casing by making 0{40} into a real (but\n> empty) revision.\n> \n>> (e.g. \"commit\" needs to notice that the\n>> result should be a root, not a child of 0{40};\n> \n> No, commits that were previously generated as orphans *would* now be\n> generated as children of the special 0{40} commit.\n\nYou would still have to have quite a bit of special cases about 0{40}\nNUL commit. Perhaps less special cases, but new special cases.\n \n[...]\n>> so it does not change the fact that the unborn branch is case\n>> is special.\n> \n> On the contrary, I believe that much special casing could be eliminated\n> and the UI made more uniform by treating everything as a descendant of a\n> special \"NULL\" commit.\n\nI don't see how this can be done in backward-compatibile way.\n\nPlease note that in Git it is quite natural to have more than one root\n(parentless) commit, even without presence of disconnected / orphan\nbranches. They are result of joining originally separate projects.\ngit.git has quite a few of them (more than 6, IIRC).\n\n-- \nJakub Narebski\n"},{"id":"183410","messageId":"CANgJU+UxB-qAJOaqKKnMkTx7fW4cyqHrGy7myhCzizBFGtnMZg@mail.gmail.com","threadId":"29464","inReplyTo":"4F27BBED.9080902@viscovery.net","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-01-31T10:11:55Z","receivedAt":"2012-01-31T10:11:55Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 31 January 2012 11:01, Johannes Sixt wrote:\n> Am 1/31/2012 9:57, schrieb Michael Haggerty:\n>> No, the idea is to avoid special casing by making 0{40} into a real (but\n>> empty) revision.\n>\n> But then why not just have git init perform the equivalent of\n>\n>  c=$(echo \"Start\" | git commit-tree $empty_tree_sha1) &&\n>  git update-ref refs/heads/master $c\n>\n> People who dislike an empty initial commit can always use \"git commit\n> --amend\" for the first \"real\" commit.\n\nBecause it would then violate a system invariant that all commits are\ndescendants of the root commit.\n\nYou can model a git commit graph as a pathway through multidimensional\nspace of all possible commit trees. From that perspective it makes\nsense that every pathway starts at the origin point of the\nmultidimensional space, which is conceptually the same as the proposed\nroot commit.\n\nAnyway, I am not saying it should change, just that from some point of\nviews it makes a lot of sense.\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"183418","messageId":"4F281780.1070804@alum.mit.edu","threadId":"29464","inReplyTo":"m3k448che9.fsf@localhost.localdomain","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-01-31T16:32:00Z","receivedAt":"2012-01-31T16:32:00Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 01/31/2012 11:09 AM, Jakub Narebski wrote:\n> I don't see how this can be done in backward-compatibile way.\n\nYes, backwards compatibility would probably prevent the NULL commit idea\nfrom ever being implemented in a literal way.\n\nBut it is conceivable that it could be faked with some strategic\n\n if sha1 == '0'*40:\n treat_as_special_null_commit\n elif len(parents) == 0:\n parents = ['0'*40]\n\nIn other words, include a little special case fakery in the data\nstructures near root commits (an O(1) amount of work) to avoid special\ncases in all commands that can touch root commits (an O(number of\ncommands) amount of work).\n\nAlternatively, the NULL commit could be a UI construct that has no\nmanifestation in the object model. This would not save implementation\nwork, but would perhaps give a more consistent way to deal with root\ncommits in the UI than the current array of --orphan etc. options.\n\n> Please note that in Git it is quite natural to have more than one root\n> (parentless) commit, even without presence of disconnected / orphan\n> branches. They are result of joining originally separate projects.\n> git.git has quite a few of them (more than 6, IIRC).\n\nI don't see the problem, unless you mean that it would be difficult to\nmerge repositories that don't link back to a NULL commit with\nhypothetical future repositories that do include a NULL commit. But a\nworld in which two kinds of repositories have to be supported is\npointless anyway, because then the git code would have to include *both*\nkinds of special cases and nothing would be gained.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"183949","messageId":"7vaa4wda60.fsf_-_@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"20120130214842.GA16149@sigill.intra.peff.net","subject":"[PATCH] branch --edit-description: protect against mistyped branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T01:26:31Z","receivedAt":"2012-02-06T01:26:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It is very easy to mistype the branch name when editing its description,\ne.g.\n\n\t$ git checkout -b my-topic master\n\t: work work work\n\t: now we are at a good point to switch working something else\n\t$ git checkout master\n\t: ah, let's write it down before we forget what we were doing\n\t$ git branch --edit-description my-tpoic\n\nThe command does not notice that branch 'my-tpoic' does not exist. It is\nnot lost (it becomes description of an unborn my-tpoic branch), but is not\nvery useful. So detect such a case and error out to reduce the grief\nfactor from this common mistake.\n\nThis incidentally also errors out --edit-description when the HEAD points\nat an unborn branch (immediately after \"init\", or \"checkout --orphan\"),\nbecause at that point, you do not even have any commit that is part of\nyour history and there is no point in describing how this particular\nbranch is different from the branch it forked off of, which is the useful\nbit of information the branch description is designed to capture.\n\nWe may want to special case the unborn case later, but that is outside the\nscope of this patch to prevent more common mistakes before 1.7.9 series\ngains too much widespread use.\n\nSigned-off-by: Junio C Hamano \n---\n\n Jeff King writes:\n\n > IOW, the problem with the current code is that it allows typos and other\n > arbitrary bogus names to be silently described, even though doing so is\n > probably an error...\n\n builtin/branch.c | 15 +++++++++++++++\n t/t3200-branch.sh | 41 +++++++++++++++++++++++++++++++++++++----\n 2 files changed, 52 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 7095718..0c1784f 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -768,6 +768,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\t\t with_commit, argv);\n \telse if (edit_description) {\n \t\tconst char *branch_name;\n+\t\tstruct strbuf branch_ref = STRBUF_INIT;\n+\n \t\tif (detached)\n \t\t\tdie(\"Cannot give description to detached HEAD\");\n \t\tif (!argc)\n@@ -776,6 +778,19 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tbranch_name = argv[0];\n \t\telse\n \t\t\tusage_with_options(builtin_branch_usage, options);\n+\n+\t\tstrbuf_addf(&branch_ref, \"refs/heads/%s\", branch_name);\n+\t\tif (!ref_exists(branch_ref.buf)) {\n+\t\t\tstrbuf_reset(&branch_ref);\n+\n+\t\t\tif (!argc)\n+\t\t\t\treturn error(\"No commit on branch '%s' yet.\",\n+\t\t\t\t\t branch_name);\n+\t\t\telse\n+\t\t\t\treturn error(\"No such branch '%s'.\", branch_name);\n+\t\t}\n+\t\tstrbuf_reset(&branch_ref);\n+\n \t\tif (edit_branch_description(branch_name))\n \t\t\treturn 1;\n \t} else if (rename) {\ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex ea82424..dd1aceb 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -3,11 +3,8 @@\n # Copyright (c) 2005 Amos Waterland\n #\n \n-test_description='git branch --foo should not create bogus branch\n+test_description='git branch assorted tests'\n \n-This test runs git branch --help and checks that the argument is properly\n-handled. Specifically, that a bogus branch is not created.\n-'\n . ./test-lib.sh\n \n test_expect_success \\\n@@ -620,4 +617,40 @@ test_expect_success 'use set-upstream on the current branch' '\n \n '\n \n+test_expect_success 'use --edit-description' '\n+\twrite_script editor <<-\\EOF &&\n+\t\techo \"New contents\" >\"$1\"\n+\tEOF\n+\tEDITOR=./editor git branch --edit-description &&\n+\t\twrite_script editor <<-\\EOF &&\n+\t\tgit stripspace -s <\"$1\" >\"EDITOR_OUTPUT\"\n+\tEOF\n+\tEDITOR=./editor git branch --edit-description &&\n+\techo \"New contents\" >expect &&\n+\ttest_cmp EDITOR_OUTPUT expect\n+'\n+\n+test_expect_success 'detect typo in branch name when using --edit-description' '\n+\twrite_script editor <<-\\EOF &&\n+\t\techo \"New contents\" >\"$1\"\n+\tEOF\n+\t(\n+\t\tEDITOR=./editor &&\n+\t\texport EDITOR &&\n+\t\ttest_must_fail git branch --edit-description no-such-branch\n+\t)\n+'\n+\n+test_expect_success 'refuse --edit-description on unborn branch for now' '\n+\twrite_script editor <<-\\EOF &&\n+\t\techo \"New contents\" >\"$1\"\n+\tEOF\n+\tgit checkout --orphan unborn &&\n+\t(\n+\t\tEDITOR=./editor &&\n+\t\texport EDITOR &&\n+\t\ttest_must_fail git branch --edit-description\n+\t)\n+'\n+\n test_done\n-- \n1.7.9.172.ge26ae\n"},{"id":"183950","messageId":"7v62fkda4e.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"7vaa4wda60.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] branch --edit-description: protect against mistyped branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T01:27:29Z","receivedAt":"2012-02-06T01:27:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> +\t\tif (!ref_exists(branch_ref.buf)) {\n> +\t\t\tstrbuf_reset(&branch_ref);\n> +\n> +\t\t\tif (!argc)\n> +\t\t\t\treturn error(\"No commit on branch '%s' yet.\",\n> +\t\t\t\t\t branch_name);\n> +\t\t\telse\n> +\t\t\t\treturn error(\"No such branch '%s'.\", branch_name);\n> +\t\t}\n> +\t\tstrbuf_reset(&branch_ref);\n> +\n\nOf course these should be strbuf_release().\n"},{"id":"183954","messageId":"7vobtcbtqa.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"20120130215043.GB16149@sigill.intra.peff.net","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T02:06:53Z","receivedAt":"2012-02-06T02:06:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Is it really worth warning? After all, by definition you are not leaving\n> any commits or useful work behind.\n\nI actually do not know if this change itself is worth doing, but if we\nwere to do this, then I think the user benefits from the warning.\n\nThe patch is made on maint-1.7.6 track for no good reason, so it may have\nsome merge conflicts around \"resolve_ref()\" vs \"resolve_refdup()\" if we\nwere to apply it on a more modern codebase, but the resolution should be\ntrivial.\n\n---\nSubject: [PATCH] git checkout -b: allow switching out of an unborn branch\n\nRunning \"git checkout -b another\" immediately after \"git init\" when you do\nnot even have a commit on 'master' is forbidden, with a readable message:\n\n $ git checkout -b another\n fatal: You are on a branch yet to be born\n\nIt is readable but not easily understandable unless the user knows what\n\"yet to be born\" really means.\n\nSo let's try allowing it and see what happens. I strongly suspect that\nthis may just shift the confusion one step further without adding much\nvalue to the resulting system, because the next question that would come\nto somebody who does not understand what \"yet to be born\" is is \"why don't\nI see 'master' in the output from 'git branch' command?\", and the new\nwarning may not be descriptive enough to explain what the user is doing.\n\nThe early part of switch_branches() that computes old is probably be\nbetter moved to the caller cmd_checkout() and used in the new code that\ndetects the \"unborn\" case, and passed as to switch_branches() as the third\nparameter. Such improvements and tests are left as an exercise for the\ninterested and motivated, as usual ;-)\n\nSigned-off-by: Junio C Hamano \n---\n builtin/checkout.c | 24 ++++++++++++++++++++++++\n 1 files changed, 24 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 4c20dae..5894f40 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -916,6 +916,19 @@ static int parse_branchname_arg(int argc, const char **argv,\n \treturn argcount;\n }\n \n+static int switch_unborn_to_new_branch(struct checkout_opts *opts, const char *old_ref)\n+{\n+\tint status;\n+\tstruct strbuf branch_ref = STRBUF_INIT;\n+\n+\tstrbuf_addf(&branch_ref, \"refs/heads/%s\", opts->new_branch);\n+\twarning(_(\"Leaving the unborn branch '%s' behind...\"),\n+\t\tskip_prefix(old_ref, \"refs/heads/\"));\n+\tstatus = create_symref(\"HEAD\", branch_ref.buf, \"checkout -b\");\n+\tstrbuf_release(&branch_ref);\n+\treturn status;\n+}\n+\n int cmd_checkout(int argc, const char **argv, const char *prefix)\n {\n \tstruct checkout_opts opts;\n@@ -1089,5 +1102,16 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \tif (opts.writeout_stage)\n \t\tdie(_(\"--ours/--theirs is incompatible with switching branches.\"));\n \n+\tif (!new.commit) {\n+\t\tunsigned char rev[20];\n+\t\tint flag, status;\n+\t\tconst char *old_ref = resolve_ref(\"HEAD\", rev, 0, &flag);\n+\n+\t\tif ((flag & REF_ISSYMREF) && is_null_sha1(rev)) {\n+\t\t\tstatus = switch_unborn_to_new_branch(&opts, old_ref);\n+\t\t\tfree((char *)old_ref);\n+\t\t\treturn status;\n+\t\t}\n+\t}\n \treturn switch_branches(&opts, &new);\n }\n-- \n1.7.9.172.ge26ae\n"},{"id":"183955","messageId":"7vk440btmx.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"7vobtcbtqa.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T02:08:54Z","receivedAt":"2012-02-06T02:08:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The patch is made on maint-1.7.6 track for no good reason, so it may have\n> some merge conflicts around \"resolve_ref()\" vs \"resolve_refdup()\" if we\n> were to apply it on a more modern codebase, but the resolution should be\n> trivial.\n\nThe resolution should look like this, just in case.\n\ndiff --cc builtin/checkout.c\nindex 5bf96ba,5894f40..41b9b34\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@@ -1079,5 -1102,16 +1092,16 @@@ int cmd_checkout(int argc, const char *\n \tif (opts.writeout_stage)\n \t\tdie(_(\"--ours/--theirs is incompatible with switching branches.\"));\n \n+ \tif (!new.commit) {\n+ \t\tunsigned char rev[20];\n+ \t\tint flag, status;\n -\t\tconst char *old_ref = resolve_ref(\"HEAD\", rev, 0, &flag);\n++\t\tchar *old_ref = resolve_refdup(\"HEAD\", rev, 0, &flag);\n+ \n+ \t\tif ((flag & REF_ISSYMREF) && is_null_sha1(rev)) {\n+ \t\t\tstatus = switch_unborn_to_new_branch(&opts, old_ref);\n -\t\t\tfree((char *)old_ref);\n++\t\t\tfree(old_ref);\n+ \t\t\treturn status;\n+ \t\t}\n+ \t}\n \treturn switch_branches(&opts, &new);\n }\n"},{"id":"183962","messageId":"20120206042043.GC29365@sigill.intra.peff.net","threadId":"29464","inReplyTo":"7vaa4wda60.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] branch --edit-description: protect against mistyped branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-06T04:20:43Z","receivedAt":"2012-02-06T04:20:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 05, 2012 at 05:26:31PM -0800, Junio C Hamano wrote:\n\n> This incidentally also errors out --edit-description when the HEAD points\n> at an unborn branch (immediately after \"init\", or \"checkout --orphan\"),\n> because at that point, you do not even have any commit that is part of\n> your history and there is no point in describing how this particular\n> branch is different from the branch it forked off of, which is the useful\n> bit of information the branch description is designed to capture.\n> \n> We may want to special case the unborn case later, but that is outside the\n> scope of this patch to prevent more common mistakes before 1.7.9 series\n> gains too much widespread use.\n\nThat sounds OK to me. I'm not even sure people will want to use\n\"--edit-description\" on an unborn pointed-to branch or not (I mentioned\nit only as \"this is a plausible use case to me that we might be\nbreaking\"). I think people will still be figuring out workflows around\nit. So it's not a big deal to wait and see.\n\n-Peff\n"},{"id":"183964","messageId":"20120206043012.GD29365@sigill.intra.peff.net","threadId":"29464","inReplyTo":"7vobtcbtqa.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-06T04:30:12Z","receivedAt":"2012-02-06T04:30:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 05, 2012 at 06:06:53PM -0800, Junio C Hamano wrote:\n\n> Subject: [PATCH] git checkout -b: allow switching out of an unborn branch\n> \n> Running \"git checkout -b another\" immediately after \"git init\" when you do\n> not even have a commit on 'master' is forbidden, with a readable message:\n> \n> $ git checkout -b another\n> fatal: You are on a branch yet to be born\n> \n> It is readable but not easily understandable unless the user knows what\n> \"yet to be born\" really means.\n> \n> So let's try allowing it and see what happens. I strongly suspect that\n> this may just shift the confusion one step further without adding much\n> value to the resulting system, because the next question that would come\n> to somebody who does not understand what \"yet to be born\" is is \"why don't\n> I see 'master' in the output from 'git branch' command?\", and the new\n> warning may not be descriptive enough to explain what the user is doing.\n\nI thought the concern wasn't confusion at the error message, but rather\n\"how do I start a new repository with a branch named something besides\n'master'?\"\n\nYou would expect:\n\n git init\n git checkout -b foo\n\nto work, but it doesn't. And there's no easy way to do what you want\n(you have to resort to plumbing to put the value in HEAD). So the issue\nis not a bad error message or a confusing situation, but that the user\nwants to accomplish X, and we don't provide a reasonable way to do it.\n\nI suspect it hasn't come up so far because the \"X\" in this case is not\nsomething people generally want to do. I.e., they are almost always\ncloning and making a new branch from old history. If they have a\nbrand-new repo, they almost certainly don't actually care what the\nbranch is called.\n\nAnd perhaps in that case we should be discouraging them from calling it\nsomething besides master (because while master is mostly convention,\nthere are a few magic spots in the code where it is treated specially,\nand departing from the convention for no good reason should be\ndiscouraged).\n\nSo I don't see \"this is just shifting confusion\" as a real argument. But\nyou could argue that it is enabling the user to do something stupid and\npointless, and for that reason it should be disallowed (and in that\ncase, it might be better for the error to say \"what you are doing is\nstupid and pointless\").\n\n-Peff\n"},{"id":"183965","messageId":"CAH5451ndjozo8-Cx3+Vc84TCjKJvCnSuOUsQS5cnqXsdc=8fMQ@mail.gmail.com","threadId":"29464","inReplyTo":"20120206043012.GD29365@sigill.intra.peff.net","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-02-06T04:42:24Z","receivedAt":"2012-02-06T04:42:24Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 6 February 2012 15:30, Jeff King wrote:\n\n> And perhaps in that case we should be discouraging them from calling it\n> something besides master (because while master is mostly convention,\n> there are a few magic spots in the code where it is treated specially,\n> and departing from the convention for no good reason should be\n> discouraged).\n\nWhat exactly are the areas where 'master' is treated specially? I\nagree that people should be discouraged from needlessly abandoning\nconvention, however I think users should have the ability to name\ntheir branches as they see fit.\n\nIf I am forced to abandon code targeted at the 'master' naming\nconvention in order to use my desired naming convention, we should fix\nthat. Additionally, if I have to either manually set a branch name\nwith plumbing commands, or delete existing branches that are generated\nautomatically with no option not to generate them, we should improve\nthe porcelain to cover these cracks.\n\nIn general, I think it plausible that in some use cases the term\n'master' might be misleading or inappropriate and users should not be\npunished for that.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"183966","messageId":"20120206050637.GA4263@sigill.intra.peff.net","threadId":"29464","inReplyTo":"CAH5451ndjozo8-Cx3+Vc84TCjKJvCnSuOUsQS5cnqXsdc=8fMQ@mail.gmail.com","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-06T05:06:37Z","receivedAt":"2012-02-06T05:06:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 06, 2012 at 03:42:24PM +1100, Andrew Ardill wrote:\n\n> On 6 February 2012 15:30, Jeff King wrote:\n> \n> > And perhaps in that case we should be discouraging them from calling it\n> > something besides master (because while master is mostly convention,\n> > there are a few magic spots in the code where it is treated specially,\n> > and departing from the convention for no good reason should be\n> > discouraged).\n> \n> What exactly are the areas where 'master' is treated specially? I\n> agree that people should be discouraged from needlessly abandoning\n> convention, however I think users should have the ability to name\n> their branches as they see fit.\n\nFairly minor stuff. Between the top of my head and a quick grep:\n\n 1. Some transports (like git://) are incapable of communicating the\n destination of a remote's symbolic ref (they see only that HEAD\n points to some specific sha1). But things like \"clone\" want to know\n where the HEAD is pointing to set up the remotes/$origin/HEAD\n link. We can guess that if HEAD and some branch have the same sha1,\n that HEAD is pointing to that branch. But you might have two or\n more such branches pointing to the same spot. In this case, we\n prefer \"master\" over other branches.\n\n This code is in guess_remote_head.\n\n 2. When merging, if the current branch is named \"master\", the default\n merge message says \"Merge branch foo\". Otherwise, it says \"Merge\n branch foo into bar\".\n\n 3. It looks like the antique \"branches\" file format defaults to\n fetching \"master\" when no branch specifier is given. I doubt anyone\n is still using this file format these days.\n\nI was actually surprised how infrequently the term \"master\" comes up in\na grep of the code. So while I wouldn't call my search exhaustive, I did\ninspect every match in the C code.\n\n> If I am forced to abandon code targeted at the 'master' naming\n> convention in order to use my desired naming convention, we should fix\n> that. Additionally, if I have to either manually set a branch name\n> with plumbing commands, or delete existing branches that are generated\n> automatically with no option not to generate them, we should improve\n> the porcelain to cover these cracks.\n> \n> In general, I think it plausible that in some use cases the term\n> 'master' might be misleading or inappropriate and users should not be\n> punished for that.\n\nI kind of agree that we shouldn't be unnecessarily restrictive. On the\nother hand, I am stretching to find the plausible reason that one would\nwant to throw away the normal convention. Code aside, it simply\nintroduces a slight communication barrier when talking with other git\nusers, and for that reason should be something you don't do lightly. I\ndon't recall seeing anybody complain seriously about it in the past six\nyears of git's existence.\n\n-Peff\n"},{"id":"183967","messageId":"7vty34a6fd.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"20120206043012.GD29365@sigill.intra.peff.net","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T05:15:34Z","receivedAt":"2012-02-06T05:15:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I thought the concern wasn't confusion at the error message, but rather\n> \"how do I start a new repository with a branch named something besides\n> 'master'?\"\n>\n> You would expect:\n>\n> git init\n> git checkout -b foo\n>\n> to work, but it doesn't. And there's no easy way to do what you want\n> (you have to resort to plumbing to put the value in HEAD). So the issue\n> is not a bad error message or a confusing situation, but that the user\n> wants to accomplish X, and we don't provide a reasonable way to do it.\n\nI think the right interface for \"I want to use 'foo' instead of 'master'\nlike everybody else\" would be:\n\n\t$ git init --some-option foo\n\nI wouldn't have any issue with that.\n"},{"id":"183968","messageId":"20120206051834.GA5062@sigill.intra.peff.net","threadId":"29464","inReplyTo":"7vty34a6fd.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-06T05:18:34Z","receivedAt":"2012-02-06T05:18:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 05, 2012 at 09:15:34PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I thought the concern wasn't confusion at the error message, but rather\n> > \"how do I start a new repository with a branch named something besides\n> > 'master'?\"\n> >\n> > You would expect:\n> >\n> > git init\n> > git checkout -b foo\n> >\n> > to work, but it doesn't. And there's no easy way to do what you want\n> > (you have to resort to plumbing to put the value in HEAD). So the issue\n> > is not a bad error message or a confusing situation, but that the user\n> > wants to accomplish X, and we don't provide a reasonable way to do it.\n> \n> I think the right interface for \"I want to use 'foo' instead of 'master'\n> like everybody else\" would be:\n> \n> \t$ git init --some-option foo\n> \n> I wouldn't have any issue with that.\n\nSure, that's one way to do it. But I don't see any point in not allowing\n\"git checkout -b\" to be another way of doing it. Is there some other use\ncase for \"git checkout -b\" from an unborn branch? Or is there some\nharmful outcome that can come from doing so that we need to be\nprotecting against? Am I missing something?\n\n-Peff\n"},{"id":"183969","messageId":"7vk440a5qw.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"20120206051834.GA5062@sigill.intra.peff.net","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T05:30:15Z","receivedAt":"2012-02-06T05:30:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Sure, that's one way to do it. But I don't see any point in not allowing\n> \"git checkout -b\" to be another way of doing it. Is there some other use\n> case for \"git checkout -b\" from an unborn branch? Or is there some\n> harmful outcome that can come from doing so that we need to be\n> protecting against? Am I missing something?\n\nMostly because it is wrong at the conceptual level to do so.\n\n\tgit checkout -b foo\n\nis a short-hand for\n\n\tgit checkout -b foo HEAD\n\nwhich is a short-hand for\n\n\tgit branch foo HEAD &&\n git checkout foo\n\nBut the last one has no chance of working if you think about it, because\n\"git branch foo $start\" is a way to start a branch at $start and you need\nto have something to point at with refs/heads/foo.\n\nSo we are breaking the equivalence between these three only when HEAD\npoints at an unborn branch.\n"},{"id":"183970","messageId":"7vfweoa5jx.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"7vk440a5qw.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T05:34:26Z","receivedAt":"2012-02-06T05:34:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> But the last one has no chance of working if you think about it, because\n> \"git branch foo $start\" is a way to start a branch at $start and you need\n> to have something to point at with refs/heads/foo.\n\n... which brings us back to your earlier point ...\n\n>> I like your patch better than trying to pass around \"0{40}\", but:\n\nwhich is why my conclusion was that \"checkout -b\" is shifting the\nconfusion around to different parts.\n\n> So we are breaking the equivalence between these three only when HEAD\n> points at an unborn branch.\n"},{"id":"183977","messageId":"20120206054558.GA7883@sigill.intra.peff.net","threadId":"29464","inReplyTo":"7vk440a5qw.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-06T05:45:58Z","receivedAt":"2012-02-06T05:45:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 05, 2012 at 09:30:15PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Sure, that's one way to do it. But I don't see any point in not allowing\n> > \"git checkout -b\" to be another way of doing it. Is there some other use\n> > case for \"git checkout -b\" from an unborn branch? Or is there some\n> > harmful outcome that can come from doing so that we need to be\n> > protecting against? Am I missing something?\n> \n> Mostly because it is wrong at the conceptual level to do so.\n> \n> \tgit checkout -b foo\n> \n> is a short-hand for\n> \n> \tgit checkout -b foo HEAD\n> \n> which is a short-hand for\n> \n> \tgit branch foo HEAD &&\n> git checkout foo\n> \n> But the last one has no chance of working if you think about it, because\n> \"git branch foo $start\" is a way to start a branch at $start and you need\n> to have something to point at with refs/heads/foo.\n> \n> So we are breaking the equivalence between these three only when HEAD\n> points at an unborn branch.\n\nI think it is only wrong at the conceptual level because you have\nspecified the concepts in such a way that it is so. That is how git does\nit _now_, but the whole point of this is to change git's behavior to\nhandle a potentially useful special case. I could also say this: \"git\ncheckout -b foo HEAD\" does two things:\n\n 1. create a new branch \"foo\" pointing to the current sha1 of HEAD\n\n 2. point the HEAD symref at refs/heads/foo\n\nAnd then the proposed behavior might amend the first point to say:\n\n 1. if HEAD points to an existing ref, then create a new branch...\n\nwhich is perfectly consistent and simple. It does violate your \"X is a\nshort-hand for Y\" above, but why is that a bad thing? It seems you are\narguing against a special case _because_ it is a special case, not\nbecause it is not a reasonable thing to do or expect.\n\nAnyway. I am still not convinced that this is even a useful thing to\nwant to do, so I am certainly not volunteering to write such a patch. So\nperhaps there is no point arguing about it.\n\n-Peff\n"},{"id":"184005","messageId":"4F2F94AC.6010800@alum.mit.edu","threadId":"29464","inReplyTo":"20120206050637.GA4263@sigill.intra.peff.net","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-02-06T08:51:56Z","receivedAt":"2012-02-06T08:51:56Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/06/2012 06:06 AM, Jeff King wrote:\n> I kind of agree that we shouldn't be unnecessarily restrictive. On the\n> other hand, I am stretching to find the plausible reason that one would\n> want to throw away the normal convention. Code aside, it simply\n> introduces a slight communication barrier when talking with other git\n> users, and for that reason should be something you don't do lightly. I\n> don't recall seeing anybody complain seriously about it in the past six\n> years of git's existence.\n\nIn the real-world situation when I noticed this bug, I wasn't trying to\nuse a nonstandard name for \"master\". What I was doing is importing a\nsnapshot of some code from another non-git project onto a \"vendor\nbranch\", which I knew I would later want to merge into my own work\n(which I planned to do on master).\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"184007","messageId":"20120206085707.GA24149@sigill.intra.peff.net","threadId":"29464","inReplyTo":"4F2F94AC.6010800@alum.mit.edu","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-06T08:57:07Z","receivedAt":"2012-02-06T08:57:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 06, 2012 at 09:51:56AM +0100, Michael Haggerty wrote:\n\n> On 02/06/2012 06:06 AM, Jeff King wrote:\n> >I don't recall seeing anybody complain seriously about it in the past\n> >six years of git's existence.\n> \n> In the real-world situation when I noticed this bug, I wasn't trying to\n> use a nonstandard name for \"master\". What I was doing is importing a\n> snapshot of some code from another non-git project onto a \"vendor\n> branch\", which I knew I would later want to merge into my own work\n> (which I planned to do on master).\n\nThanks, that sounds like a very reasonable use case. I stand corrected.\n\n(For some reason I thought you ran across it accidentally while mucking\nwith \"--edit-description\", since were talking about that an unborn\nbranches in a nearby thread).\n\n-Peff\n\nPS I probably would have done it as:\n\n git init vendor\n cd vendor\n import import import\n cd ..\n\n git init project\n cd project\n git fetch ../vendor master:vendor\n\n but I don't think there's anything wrong with your approach (in fact,\n it's slightly more efficient).\n"},{"id":"184008","messageId":"4F2F9661.2020606@alum.mit.edu","threadId":"29464","inReplyTo":"7vk440a5qw.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-02-06T08:59:13Z","receivedAt":"2012-02-06T08:59:13Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/06/2012 06:30 AM, Junio C Hamano wrote:\n> Jeff King writes:\n> \n>> Sure, that's one way to do it. But I don't see any point in not allowing\n>> \"git checkout -b\" to be another way of doing it. Is there some other use\n>> case for \"git checkout -b\" from an unborn branch? Or is there some\n>> harmful outcome that can come from doing so that we need to be\n>> protecting against? Am I missing something?\n> \n> Mostly because it is wrong at the conceptual level to do so.\n> \n> \tgit checkout -b foo\n> \n> is a short-hand for\n> \n> \tgit checkout -b foo HEAD\n> \n> which is a short-hand for\n> \n> \tgit branch foo HEAD &&\n> git checkout foo\n> \n> But the last one has no chance of working if you think about it, because\n> \"git branch foo $start\" is a way to start a branch at $start and you need\n> to have something to point at with refs/heads/foo.\n> \n> So we are breaking the equivalence between these three only when HEAD\n> points at an unborn branch.\n\nYou are thinking too much like a developer and not like a user. For a user,\n\n git checkout -b foo\n\nis a short-hand for\n\n \"create and check out a branch at my current state\"\n\nand the interpretation of what that means when I am on an unborn branch\nseems unambiguous.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"184041","messageId":"7vpqdr7rn0.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"20120206085707.GA24149@sigill.intra.peff.net","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T18:17:55Z","receivedAt":"2012-02-06T18:17:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> PS I probably would have done it as:\n>\n> git init vendor\n> cd vendor\n> import import import\n> cd ..\n>\n> git init project\n> cd project\n> git fetch ../vendor master:vendor\n>\n> but I don't think there's anything wrong with your approach (in fact,\n> it's slightly more efficient).\n\nProbably I am slower than my usual slow self this morning. Does Michael's\napproach go like this:\n\n\tgit init project\n cd project\n import import import\n git branch -m vendor\n git checkout -b master\n\nto fork from third-party codebase?\n\nOr Michael had his own 'master' already and wanted an independent orphaned\nhistory from vendor, perhaps like this?\n\n\tgit init project\n cd project\n work work work\n git checkout --orphan vendor\n : perhaps \"git clean -f\" here???\n import import import\n git checkout master\n : rootless merge???\n git merge vendor\n"},{"id":"184042","messageId":"7vliof7r0n.fsf@alter.siamese.dyndns.org","threadId":"29464","inReplyTo":"4F2F9661.2020606@alum.mit.edu","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T18:31:20Z","receivedAt":"2012-02-06T18:31:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n>> So we are breaking the equivalence between these three only when HEAD\n>> points at an unborn branch.\n>\n> You are thinking too much like a developer and not like a user. For a user,\n>\n> git checkout -b foo\n>\n> is a short-hand for\n>\n> \"create and check out a branch at my current state\"\n>\n> and the interpretation of what that means when I am on an unborn branch\n> seems unambiguous.\n\nOk, that is a very good explanation.\n\nCare to come up with a patch to Documentation/git-checkout.txt? The\ndescription there strongly implies that is an existing\ncommit. Not much is said about what the lack of mean when\nit describes \"checkout -b\", and a standalone description of \nsays \"The name of a comit at which to start... Defaults to HEAD\". These\nneed to be loosened and described in terms of the closer-to-the-user \"at\nmy current state\".\n"},{"id":"184043","messageId":"CANgJU+Xz1adaungdOnosYwvYOXYf1F=PTub2nJYn=-1BiRAFeg@mail.gmail.com","threadId":"29464","inReplyTo":"CAH5451ndjozo8-Cx3+Vc84TCjKJvCnSuOUsQS5cnqXsdc=8fMQ@mail.gmail.com","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-02-06T18:39:15Z","receivedAt":"2012-02-06T18:39:15Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 6 February 2012 05:42, Andrew Ardill wrote:\n> On 6 February 2012 15:30, Jeff King wrote:\n>\n>> And perhaps in that case we should be discouraging them from calling it\n>> something besides master (because while master is mostly convention,\n>> there are a few magic spots in the code where it is treated specially,\n>> and departing from the convention for no good reason should be\n>> discouraged).\n>\n> What exactly are the areas where 'master' is treated specially? I\n> agree that people should be discouraged from needlessly abandoning\n> convention, however I think users should have the ability to name\n> their branches as they see fit.\n\nFWIW, we at $work have used a repo without a master branch at all\nsince the very beginning and never noticed a problem with it.\n\nAlthough we *did* rename the original master to \"trunk\".\n\nWe did this because we felt that in a scenario where there is a\ndesignated central \"master repo\" that the use of \"master branch\" would\nget really confusing, so we have a master repo, whos main branch is\n\"trunk\".\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"184050","messageId":"20120206201440.GB30776@sigill.intra.peff.net","threadId":"29464","inReplyTo":"7vpqdr7rn0.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-06T20:14:40Z","receivedAt":"2012-02-06T20:14:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 06, 2012 at 10:17:55AM -0800, Junio C Hamano wrote:\n\n> > PS I probably would have done it as:\n> >\n> > git init vendor\n> > cd vendor\n> > import import import\n> > cd ..\n> >\n> > git init project\n> > cd project\n> > git fetch ../vendor master:vendor\n> >\n> > but I don't think there's anything wrong with your approach (in fact,\n> > it's slightly more efficient).\n> \n> Probably I am slower than my usual slow self this morning. Does Michael's\n> approach go like this:\n> \n> \tgit init project\n> cd project\n> import import import\n> git branch -m vendor\n> git checkout -b master\n> \n> to fork from third-party codebase?\n\nI thought it would have been:\n\n git init project\n cd project\n git checkout -b vendor\n import import import\n git checkout -b master\n modify modify modify\n\nbut he can probably say more.\n\n-Peff\n"},{"id":"184107","messageId":"4F30DAFB.5050906@alum.mit.edu","threadId":"29464","inReplyTo":"7vpqdr7rn0.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: \"git checkout -b\" should be allowed in empty repo","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-02-07T08:04:11Z","receivedAt":"2012-02-07T08:04:11Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/06/2012 07:17 PM, Junio C Hamano wrote:\n> Jeff King writes:\n> Probably I am slower than my usual slow self this morning. Does Michael's\n> approach go like this:\n> \n> \tgit init project\n> cd project\n> import import import\n> git branch -m vendor\n> git checkout -b master\n> \n> to fork from third-party codebase?\n\nI'm not really forking the third-party code; I'm just importing a\nsnapshot to a particular subdirectory of my own project. I wanted to do\nsomething like:\n\n git init project\n cd project\n git checkout -b vendor\n import import import commit (into subdirectory \"foo\")\n git checkout --orphan master\n git clean -fxd\n hack commit hack commit\n # Then when the vendor stuff is logically needed in master:\n git merge vendor\n\nWith the option to import later snapshots of the third-party code to the\n\"vendor\" branch then re-merge it to master.\n\n> Care to come up with a patch to Documentation/git-checkout.txt? The\n> description there strongly implies that is an existing\n> commit. Not much is said about what the lack of mean when\n> it describes \"checkout -b\", and a standalone description of \n> says \"The name of a comit at which to start... Defaults to HEAD\". These\n> need to be loosened and described in terms of the closer-to-the-user \"at\n> my current state\".\n\nI'll work on it as soon as I have time.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}