{"thread":{"id":"20509","subject":"fatal: bad revision 'HEAD'","startedAt":"2009-08-09T21:15:46Z","lastAt":"2009-08-13T05:10:58Z","messageCount":11,"participants":["Joel Mahoney","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"120090","messageId":"06DCECD0-45F0-4695-86D4-7C54EFE4E640@gmail.com","threadId":"20509","inReplyTo":null,"subject":"fatal: bad revision 'HEAD'","fromName":"Joel Mahoney","fromEmail":"joelmahoney@gmail.com","sentAt":"2009-08-09T21:15:46Z","receivedAt":"2009-08-09T21:15:46Z","isPatch":false,"sender":{"key":"joelmahoney@gmail.com","avatar":null},"body":"Hello,\n\nI am having trouble installing Ruby on Rails plugins from github.   \nwhen I run e.g. script/install plugin git://github.com/thoughtbot/ \npaperclip.git I get:\n\n > Initialized empty Git repository in /path/to/my/project/vendor/ \nplugins/paperclip/.git/\n > fatal: bad revision 'HEAD'\n > refusing to pull with rebase: your working tree is not up-to-date\n\nI don't have any problems with git in general, but this error happens  \nevery time I try to install from github - even when it's a brand new  \nrails app.\n\nthe github support team tells me it looks like a git issue - any  \nsuggestions would be appreciated!\n\nthanks,\nJoel\n"},{"id":"120101","messageId":"20090810011803.GA435@coredump.intra.peff.net","threadId":"20509","inReplyTo":"06DCECD0-45F0-4695-86D4-7C54EFE4E640@gmail.com","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-10T01:18:03Z","receivedAt":"2009-08-10T01:18:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 09, 2009 at 03:15:46PM -0600, Joel Mahoney wrote:\n\n> I am having trouble installing Ruby on Rails plugins from github.\n> when I run e.g. script/install plugin git://github.com/thoughtbot/\n> paperclip.git I get:\n> \n> > Initialized empty Git repository in /path/to/my/project/vendor/\n> plugins/paperclip/.git/\n> > fatal: bad revision 'HEAD'\n> > refusing to pull with rebase: your working tree is not up-to-date\n\nI can \"git clone\" that repository just fine. What is it exactly that\ninstalling a Rails plugin does with git? Can you try setting GIT_TRACE=1\nin the environment and running your script to show us what git commands\nit is executing?\n\n-Peff\n"},{"id":"120360","messageId":"20090812032740.GA26089@coredump.intra.peff.net","threadId":"20509","inReplyTo":"C44788EB-02BA-4D69-8091-9E97827223A0@gmail.com","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-12T03:27:40Z","receivedAt":"2009-08-12T03:27:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[re-adding git@vger, since this discussion really belongs on the list]\n\nOn Tue, Aug 11, 2009 at 10:30:49AM -0600, Joel Mahoney wrote:\n\n> here's what I get now:\n> \n> trace: built-in: git 'init'\n> Initialized empty Git repository in /path/to/project/vendor/plugins/\n> paperclip/.git/\n> trace: exec: 'git-pull' '--depth' '1' 'git://github.com/thoughtbot/\n> paperclip.git'\n> trace: built-in: git 'rev-parse' '--git-dir'\n> trace: built-in: git 'rev-parse' '--is-inside-work-tree'\n> trace: built-in: git 'rev-parse' '--show-cdup'\n> trace: built-in: git 'ls-files' '-u'\n> trace: built-in: git 'symbolic-ref' '-q' 'HEAD'\n> trace: built-in: git 'config' '--bool' 'branch.master.rebase'\n> trace: built-in: git 'update-index' '--ignore-submodules' '--refresh'\n> trace: built-in: git 'diff-files' '--ignore-submodules' '--quiet'\n> trace: built-in: git 'diff-index' '--ignore-submodules' '--cached'\n> '--quiet' 'HEAD' '--'\n> fatal: bad revision 'HEAD'\n> refusing to pull with rebase: your working tree is not up-to-date\n\nI was able to replicate your problem, but only if I set\nbranch.master.rebase to \"true\" in my user-wide git config (i.e.,\n~/.gitconfig). It looks like \"git pull\" is not capable of handling a\nrebase when you have no commits yet.\n\nI'm slightly dubious that such a configuration is sane, but probably\n\"git pull\" should handle this case anyway, as you can easily replicate\nit without config by doing:\n\n  git init && git pull --rebase /any/git/repo\n\nPatch is below.\n\n-- >8 --\nSubject: [PATCH] allow pull --rebase on branch yet to be born\n\nWhen doing a \"pull --rebase\", we check to make sure that the\nindex and working tree are clean. The index-clean check\ncompares the index against HEAD. The test erroneously\nreports dirtiness if we don't have a HEAD yet.\n\nIn the case that we don't have a HEAD, we should just check\nif the index has anything in it, which we can do by\ncomparing to the empty tree.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nActually, this test is slightly more strict than the \"index dirty\" check\nin git-rebase.sh itself. That test does \"git diff-index HEAD\", but\ndoesn't check the return code. It actually looks at whether it generates\noutput. So it would consider an index with something in it on a branch\nyet-to-be-born to be clean, which is perhaps wrong.\n\nSuch a thing seems pretty unlikely in practice, though. I don't know if\nit is worth making the two tests the same (maybe it is worth refactoring\ninto an index_is_clean function in git-sh-setup).\n\n git-pull.sh     |    8 +++++++-\n t/t5520-pull.sh |   11 +++++++++++\n 2 files changed, 18 insertions(+), 1 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 0f24182..427b5c6 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -119,9 +119,15 @@ error_on_no_merge_candidates () {\n }\n \n test true = \"$rebase\" && {\n+\tif git rev-parse -q --verify HEAD >/dev/null; then\n+\t\tparent_tree=HEAD\n+\telse # empty tree\n+\t\tparent_tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904\n+\tfi\n+\n \tgit update-index --ignore-submodules --refresh &&\n \tgit diff-files --ignore-submodules --quiet &&\n-\tgit diff-index --ignore-submodules --cached --quiet HEAD -- ||\n+\tgit diff-index --ignore-submodules --cached --quiet $parent_tree -- ||\n \tdie \"refusing to pull with rebase: your working tree is not up-to-date\"\n \n \toldremoteref= &&\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex e78d402..dd2ee84 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -149,4 +149,15 @@ test_expect_success 'pull --rebase dies early with dirty working directory' '\n \n '\n \n+test_expect_success 'pull --rebase works on branch yet to be born' '\n+\tgit rev-parse master >expect &&\n+\tmkdir empty_repo &&\n+\t(cd empty_repo &&\n+\t git init &&\n+\t git pull --rebase .. master &&\n+\t git rev-parse HEAD >../actual\n+\t) &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n-- \n1.6.4.228.g9ab2.dirty\n"},{"id":"120383","messageId":"7v7hx98otz.fsf@alter.siamese.dyndns.org","threadId":"20509","inReplyTo":"20090812032740.GA26089@coredump.intra.peff.net","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-12T07:37:44Z","receivedAt":"2009-08-12T07:37:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I was able to replicate your problem, but only if I set\n> branch.master.rebase to \"true\" in my user-wide git config (i.e.,\n> ~/.gitconfig). It looks like \"git pull\" is not capable of handling a\n> rebase when you have no commits yet.\n\nIt does sound sick to store such a setting in $HOME/.gitconfig file, when\nthe variable is clearly per-repository.  As you wrote, you can easily\ntrigger it with an explicit --rebase, but again, it is insane to ask\n\"rebase\" when you clearly do not have anything.\n\nBut just like we twisted the definition of merge to mean \"merging\nsomething into nothing yields that something\", we could twist the\ndefinition of rebase to mean \"rebasing nothing on top of something result\nin that something\".  It sort of makes sense in a twisted way.\n\n> diff --git a/git-pull.sh b/git-pull.sh\n> index 0f24182..427b5c6 100755\n> --- a/git-pull.sh\n> +++ b/git-pull.sh\n> @@ -119,9 +119,15 @@ error_on_no_merge_candidates () {\n>  }\n>  \n>  test true = \"$rebase\" && {\n> +\tif git rev-parse -q --verify HEAD >/dev/null; then\n> +\t\tparent_tree=HEAD\n> +\telse # empty tree\n> +\t\tparent_tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904\n> +\tfi\n> +\n>  \tgit update-index --ignore-submodules --refresh &&\n>  \tgit diff-files --ignore-submodules --quiet &&\n> -\tgit diff-index --ignore-submodules --cached --quiet HEAD -- ||\n> +\tgit diff-index --ignore-submodules --cached --quiet $parent_tree -- ||\n>  \tdie \"refusing to pull with rebase: your working tree is not up-to-date\"\n\nTwo comments.\n\n * Is \"rev-parse -q --verify\" a safe test to guarantee that HEAD is\n   unborn?  Shouldn't we be checking with \"symbolic-ref\" or something?\n\n * In such an \"unborn branch\" case, by definition, a non-empty index won't\n   be based on whatever we are pulling down from the remote.  So how about\n   doing something like the following instead?\n\n\tif on unborn branch\n\tthen\n\t\tif test -f \"$GIT_DIR/index\"\n                then\n\t\t\tdie \"refusing to update; you have a non-empty index\"\n\t\tfi\n\telse\n\t\t... existing tests against HEAD ...\n\tfi\n"},{"id":"120387","messageId":"20090812075833.GF15152@coredump.intra.peff.net","threadId":"20509","inReplyTo":"7v7hx98otz.fsf@alter.siamese.dyndns.org","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-12T07:58:33Z","receivedAt":"2009-08-12T07:58:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 12, 2009 at 12:37:44AM -0700, Junio C Hamano wrote:\n\n> But just like we twisted the definition of merge to mean \"merging\n> something into nothing yields that something\", we could twist the\n> definition of rebase to mean \"rebasing nothing on top of something result\n> in that something\".  It sort of makes sense in a twisted way.\n\nI dunno. It doesn't seem all that twisted to me.\n\nBut like many of the \"branch to be born\" and \"initial commit\" edge cases\nwe have dealt with, it is not so much about somebody intentionally\ntriggering this as it is about doing something sane when some script\n_does_ trigger it. And I think the sane thing is obvious and easy to do\nhere, so why not?\n\n>  * Is \"rev-parse -q --verify\" a safe test to guarantee that HEAD is\n>    unborn?  Shouldn't we be checking with \"symbolic-ref\" or something?\n\nI'm not sure. The test in git-checkout, for example, seems to basically\njust be looking up HEAD as a commit. If it doesn't work, then the branch\nis to-be-born (see switch_branches in builtin-checkout.c).\n\nWhich is more or less what's happening here (except we don't check that\nthe type is a commit).\n\nWith symbolic-ref, I guess we could find out what the ref is, and check\nto see if _that_ exists. But I can't think of a situation where that\nwould be meaningfully different than just resolving HEAD. Obviously\ndetached HEADs come to mind, but wouldn't you then by definition not be\na branch-to-be-born, which is what this rev-parse test would tell you?\n\n>  * In such an \"unborn branch\" case, by definition, a non-empty index won't\n>    be based on whatever we are pulling down from the remote.  So how about\n>    doing something like the following instead?\n> \n> \tif on unborn branch\n> \tthen\n> \t\tif test -f \"$GIT_DIR/index\"\n>                 then\n> \t\t\tdie \"refusing to update; you have a non-empty index\"\n> \t\tfi\n> \telse\n> \t\t... existing tests against HEAD ...\n> \tfi\n\nYeah, I think that is a better idea. Do you want to tweak the patch, or\nshould I re-submit?\n\n-Peff\n"},{"id":"120462","messageId":"7vab24ve97.fsf@alter.siamese.dyndns.org","threadId":"20509","inReplyTo":"20090812075833.GF15152@coredump.intra.peff.net","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-12T22:49:56Z","receivedAt":"2009-08-12T22:49:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Yeah, I think that is a better idea. Do you want to tweak the patch, or\n> should I re-submit?\n\nI'll do this then.\n\n-- >8 --\nFrom: Jeff King <peff@peff.net>\nDate: Tue, 11 Aug 2009 23:27:40 -0400\nSubject: [PATCH] Subject: [PATCH] allow pull --rebase on branch yet to be born\n\nWhen doing a \"pull --rebase\", we check to make sure that the index and\nworking tree are clean. The index-clean check compares the index against\nHEAD. The test erroneously reports dirtiness if we don't have a HEAD yet.\n\nIn such an \"unborn branch\" case, by definition, a non-empty index won't\nbe based on whatever we are pulling down from the remote, and will lose\nthe local change.  Just check if $GIT_DIR/index exists and error out.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n git-pull.sh     |   18 +++++++++++++-----\n t/t5520-pull.sh |   11 +++++++++++\n 2 files changed, 24 insertions(+), 5 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 0f24182..0bbd5bf 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -119,11 +119,19 @@ error_on_no_merge_candidates () {\n }\n \n test true = \"$rebase\" && {\n-\tgit update-index --ignore-submodules --refresh &&\n-\tgit diff-files --ignore-submodules --quiet &&\n-\tgit diff-index --ignore-submodules --cached --quiet HEAD -- ||\n-\tdie \"refusing to pull with rebase: your working tree is not up-to-date\"\n-\n+\tif ! git rev-parse -q --verify HEAD >/dev/null\n+\tthen\n+\t\t# On an unborn branch\n+\t\tif test -f \"$GIT_DIR/index\"\n+\t\tthen\n+\t\t\tdie \"updating an unborn branch with changes added to the index\"\n+\t\tfi\n+\telse\n+\t\tgit update-index --ignore-submodules --refresh &&\n+\t\tgit diff-files --ignore-submodules --quiet &&\n+\t\tgit diff-index --ignore-submodules --cached --quiet HEAD -- ||\n+\t\tdie \"refusing to pull with rebase: your working tree is not up-to-date\"\n+\tfi\n \toldremoteref= &&\n \t. git-parse-remote &&\n \tremoteref=\"$(get_remote_merge_branch \"$@\" 2>/dev/null)\" &&\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex e78d402..dd2ee84 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -149,4 +149,15 @@ test_expect_success 'pull --rebase dies early with dirty working directory' '\n \n '\n \n+test_expect_success 'pull --rebase works on branch yet to be born' '\n+\tgit rev-parse master >expect &&\n+\tmkdir empty_repo &&\n+\t(cd empty_repo &&\n+\t git init &&\n+\t git pull --rebase .. master &&\n+\t git rev-parse HEAD >../actual\n+\t) &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n-- \n1.6.4.196.gd1fd8\n"},{"id":"120472","messageId":"20090813023137.GA17358@coredump.intra.peff.net","threadId":"20509","inReplyTo":"7vab24ve97.fsf@alter.siamese.dyndns.org","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-13T02:31:37Z","receivedAt":"2009-08-13T02:31:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 12, 2009 at 03:49:56PM -0700, Junio C Hamano wrote:\n\n> When doing a \"pull --rebase\", we check to make sure that the index and\n> working tree are clean. The index-clean check compares the index against\n> HEAD. The test erroneously reports dirtiness if we don't have a HEAD yet.\n> \n> In such an \"unborn branch\" case, by definition, a non-empty index won't\n> be based on whatever we are pulling down from the remote, and will lose\n> the local change.  Just check if $GIT_DIR/index exists and error out.\n> \n> Signed-off-by: Jeff King <peff@peff.net>\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\nLooks sane to me, but see below.\n\n> +\t\t# On an unborn branch\n> +\t\tif test -f \"$GIT_DIR/index\"\n> +\t\tthen\n> +\t\t\tdie \"updating an unborn branch with changes added to the index\"\n> +\t\tfi\n\nI had a brief moment where I thought this might not actually be\nsufficient. That is, can somebody create an unborn branch in an existing\nrepo (e.g., because they want an alternate project root) in such a way\nthat they have an index, but it is empty? In which case we should be\nactually checking for index emptiness instead of existence.\n\nI.e., I have done in the past (but not frequently):\n\n  git symbolic-ref HEAD refs/heads/to-be-born\n\nin an existing repository to create a new root. But I don't think we\nreally need to worry about that case:\n\n  1. It is somewhat crazy and rare in the first place. Even more crazy\n     and rare would be to \"git pull --rebase\" immediately afterwards.\n\n  2. If you _did_ have an index, either:\n\n     2a. You want to keep it, in which case your check is sane.\n\n     2b. You want to start fresh, in which case your next step would be\n         be \"rm -f .git/index\".\n\nThe only way this check would not be OK is is if you did something like:\n\n  git symbolic-ref HEAD refs/heads/new-branch\n  git ls-files | xargs git rm --cached\n  git pull --rebase ...\n\nwhich just seems crazy.\n\nSo I think I have convinced myself that what you have is fine, but I\njust wanted a sanity check.\n\n-Peff\n"},{"id":"120481","messageId":"7v1vngmitn.fsf@alter.siamese.dyndns.org","threadId":"20509","inReplyTo":"20090813023137.GA17358@coredump.intra.peff.net","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-13T04:36:04Z","receivedAt":"2009-08-13T04:36:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I.e., I have done in the past (but not frequently):\n>\n>   git symbolic-ref HEAD refs/heads/to-be-born\n>\n> in an existing repository to create a new root.\n\nI honestly do not know of a sane reason (other than \"because I can\")\nanybody would want to _start_ a new root in a repository with an existing\nhistory.  And doing a \"pull\" with or without --rebase immediately after\nstarting a new root is doubly insane, as you say.\n\nI do not think _ending up to_ have more than one root in your repository\nis necessarily insane.  You may find a related project that earlier\nstarted independently but later turned out to be better off managed\ntogether with your project, and at that point you may perform Linus's\n\"coolest merge ever\" to bind the two histories together, resulting in a\nhistory with more than one root.\n\nBut that is the kind of \"ending up to have\" I am talking about; it is not\nsomething you _aim to_ create on purpose.  If you want to _start_ a\nseparate history, and if you are sane, you would start the separate\nhistory in a separate repository.\n"},{"id":"120482","messageId":"20090813043855.GA21158@coredump.intra.peff.net","threadId":"20509","inReplyTo":"7v1vngmitn.fsf@alter.siamese.dyndns.org","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-13T04:38:55Z","receivedAt":"2009-08-13T04:38:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 12, 2009 at 09:36:04PM -0700, Junio C Hamano wrote:\n\n> I honestly do not know of a sane reason (other than \"because I can\")\n> anybody would want to _start_ a new root in a repository with an existing\n> history.  And doing a \"pull\" with or without --rebase immediately after\n> starting a new root is doubly insane, as you say.\n\nIIRC, the reason I did it was to throw away history, starting a new root\nat the current state. Which is at least a little bit sane, though I\nthink I might just do it with a graft and filter-branch these days.\n\n> But that is the kind of \"ending up to have\" I am talking about; it is not\n> something you _aim to_ create on purpose.  If you want to _start_ a\n> separate history, and if you are sane, you would start the separate\n> history in a separate repository.\n\nAgreed. Let's not worry about it, then.\n\n-Peff\n"},{"id":"120483","messageId":"89456E84-1A85-4D0C-9643-C191EE877E61@gmail.com","threadId":"20509","inReplyTo":"20090813043855.GA21158@coredump.intra.peff.net","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Joel Mahoney","fromEmail":"joelmahoney@gmail.com","sentAt":"2009-08-13T05:02:45Z","receivedAt":"2009-08-13T05:02:45Z","isPatch":false,"sender":{"key":"joelmahoney@gmail.com","avatar":null},"body":"Hello,\n\nI'm not sure I completely understand where you guys are at with this  \nthread : - ) but I thought I would mention that the question arose  \nfrom my inability to install a plugin into a Ruby on Rails project  \nbased on my having (unknowingly) set branch.master.rebase = true.\n\nI bring this up because a lot of people are getting their first  \nexposure to git through Rails/github, and installing plugins in Rails  \nis (I think) a good example of brining an existing history (the  \nplugin) into a separate repository (your project).  and because this  \nmaneuver is built into the \"./script/plugin install\" action, it is not  \nsomething that cannot be easily customized.\n\nagain, I may be a little off track here, but I thought I would remind  \nyou of the original context for what that is worth : - )\n\nthanks again for your help!\n\nJoel\n\n\nOn Aug 12, 2009, at 10:38 PM, Jeff King wrote:\n\n> On Wed, Aug 12, 2009 at 09:36:04PM -0700, Junio C Hamano wrote:\n>\n>> I honestly do not know of a sane reason (other than \"because I can\")\n>> anybody would want to _start_ a new root in a repository with an  \n>> existing\n>> history.  And doing a \"pull\" with or without --rebase immediately  \n>> after\n>> starting a new root is doubly insane, as you say.\n>\n> IIRC, the reason I did it was to throw away history, starting a new  \n> root\n> at the current state. Which is at least a little bit sane, though I\n> think I might just do it with a graft and filter-branch these days.\n>\n>> But that is the kind of \"ending up to have\" I am talking about; it  \n>> is not\n>> something you _aim to_ create on purpose.  If you want to _start_ a\n>> separate history, and if you are sane, you would start the separate\n>> history in a separate repository.\n>\n> Agreed. Let's not worry about it, then.\n>\n> -Peff\n"},{"id":"120489","messageId":"20090813051058.GA25830@coredump.intra.peff.net","threadId":"20509","inReplyTo":"89456E84-1A85-4D0C-9643-C191EE877E61@gmail.com","subject":"Re: fatal: bad revision 'HEAD'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-13T05:10:58Z","receivedAt":"2009-08-13T05:10:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 12, 2009 at 11:02:45PM -0600, Joel Mahoney wrote:\n\n> I'm not sure I completely understand where you guys are at with this\n> thread : - ) but I thought I would mention that the question arose\n> from my inability to install a plugin into a Ruby on Rails project\n> based on my having (unknowingly) set branch.master.rebase = true.\n>\n> I bring this up because a lot of people are getting their first\n> exposure to git through Rails/github, and installing plugins in Rails\n> is (I think) a good example of brining an existing history (the\n> plugin) into a separate repository (your project).  and because this\n> maneuver is built into the \"./script/plugin install\" action, it is\n> not something that cannot be easily customized.\n\nYes, the discussion moved away bit from your original issue. To\nsummarize what is happening:\n\n  - Setting branch.master.rebase in your ~/.gitconfig is probably not a\n    good idea, as that tends to be a per-repository property, anyway.\n    You can work around the problem for now by removing it.\n\n  - Junio has committed a patch to fix the bug. It will definitely be in\n    v1.6.5. If this is a common setup for Rails people, maybe we should\n    consider putting it into 'maint' for v1.6.4.1.\n\n-Peff\n"}]}