{"thread":{"id":"22672","subject":"Fatal error running status in new repo","startedAt":"2010-02-16T04:19:45Z","lastAt":"2010-02-17T06:10:05Z","messageCount":8,"participants":["Jacob Helwig","Jeff King","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"134697","messageId":"20100216041945.GB10296@vfb-9.home","threadId":"22672","inReplyTo":null,"subject":"Fatal error running status in new repo","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-02-16T04:19:45Z","receivedAt":"2010-02-16T04:19:45Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"I just noticed this when creating a new repo for a project.\n\n\n$ mkdir tmp\n$ cd tmp\n$ git init\nInitialized empty shared Git repository in /home/jhe/projects/tmp/.git/\n$ git status\n# On branch master\n#\n# Initial commit\n#\nwarning: ignoring dangling symref HEAD.\nfatal: bad revision 'HEAD'\nnothing to commit (create/copy files and use \"git add\" to track)\n$ echo $?\n0\n$ git --version\ngit version 1.7.0\n\n\nSeems a bit silly that \"git status\" should be issuing warnings, and\nfatal errors (especially when the exit code is still 0), when run before\nthe first commit has been created in a brand new repository.\n\nThe warnings make sense if you know what's going on behind the scenes,\nbut seem like the kind of thing that could scare someone new to git when\nthey haven't actually done anything wrong at this point.\n\n-- \nJacob Helwig\n"},{"id":"134700","messageId":"20100216060528.GB2169@coredump.intra.peff.net","threadId":"22672","inReplyTo":"20100216041945.GB10296@vfb-9.home","subject":"Re: Fatal error running status in new repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-16T06:05:28Z","receivedAt":"2010-02-16T06:05:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 15, 2010 at 08:19:45PM -0800, Jacob Helwig wrote:\n\n> I just noticed this when creating a new repo for a project.\n> \n> $ mkdir tmp\n> $ cd tmp\n> $ git init\n> Initialized empty shared Git repository in /home/jhe/projects/tmp/.git/\n> $ git status\n> # On branch master\n> #\n> # Initial commit\n> #\n> warning: ignoring dangling symref HEAD.\n> fatal: bad revision 'HEAD'\n> nothing to commit (create/copy files and use \"git add\" to track)\n> $ echo $?\n> 0\n> $ git --version\n> git version 1.7.0\n\nI can't reproduce it here:\n\n  $ mkdir tmp && cd tmp && git init && git status\n  Initialized empty Git repository in /home/peff/tmp/.git/\n  # On branch master\n  #\n  # Initial commit\n  #\n  nothing to commit (create/copy files and use \"git add\" to track)\n\nFurthermore, the \"ignoring dangling symref\" message can only come from\none place (sha1_name.c:285), and is specifically protected by a\nconditional making sure that the refname is not \"HEAD\". Which is just\nplain weird.\n\nDo you have anything strange in your ~/.gitconfig? Can you try running\nwith GIT_TRACE=1 to make sure we are not invoking some sub-command or\nsomething? Did you build git yourself? Can you double-check with a \"make\nclean && make\" that a newly built version exhibits the problem?\n\n> Seems a bit silly that \"git status\" should be issuing warnings, and\n> fatal errors (especially when the exit code is still 0), when run before\n> the first commit has been created in a brand new repository.\n> \n> The warnings make sense if you know what's going on behind the scenes,\n> but seem like the kind of thing that could scare someone new to git when\n> they haven't actually done anything wrong at this point.\n\nAgreed. These warnings absolutely should not be shown, but I don't\nreally understand what is showing them.\n\n-Peff\n"},{"id":"134701","messageId":"20100216062422.GC10296@vfb-9.home","threadId":"22672","inReplyTo":"20100216060528.GB2169@coredump.intra.peff.net","subject":"Re: Fatal error running status in new repo","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-02-16T06:24:22Z","receivedAt":"2010-02-16T06:24:22Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On 01:05 Tue 16 Feb     , Jeff King wrote:\n> On Mon, Feb 15, 2010 at 08:19:45PM -0800, Jacob Helwig wrote:\n> \n> > I just noticed this when creating a new repo for a project.\n> > \n> > $ mkdir tmp\n> > $ cd tmp\n> > $ git init\n> > Initialized empty shared Git repository in /home/jhe/projects/tmp/.git/\n> > $ git status\n> > # On branch master\n> > #\n> > # Initial commit\n> > #\n> > warning: ignoring dangling symref HEAD.\n> > fatal: bad revision 'HEAD'\n> > nothing to commit (create/copy files and use \"git add\" to track)\n> > $ echo $?\n> > 0\n> > $ git --version\n> > git version 1.7.0\n> \n> I can't reproduce it here:\n> \n>   $ mkdir tmp && cd tmp && git init && git status\n>   Initialized empty Git repository in /home/peff/tmp/.git/\n>   # On branch master\n>   #\n>   # Initial commit\n>   #\n>   nothing to commit (create/copy files and use \"git add\" to track)\n> \n> Furthermore, the \"ignoring dangling symref\" message can only come from\n> one place (sha1_name.c:285), and is specifically protected by a\n> conditional making sure that the refname is not \"HEAD\". Which is just\n> plain weird.\n> \n> Do you have anything strange in your ~/.gitconfig? Can you try running\n> with GIT_TRACE=1 to make sure we are not invoking some sub-command or\n> something? Did you build git yourself? Can you double-check with a \"make\n> clean && make\" that a newly built version exhibits the problem?\n> \n> > Seems a bit silly that \"git status\" should be issuing warnings, and\n> > fatal errors (especially when the exit code is still 0), when run before\n> > the first commit has been created in a brand new repository.\n> > \n> > The warnings make sense if you know what's going on behind the scenes,\n> > but seem like the kind of thing that could scare someone new to git when\n> > they haven't actually done anything wrong at this point.\n> \n> Agreed. These warnings absolutely should not be shown, but I don't\n> really understand what is showing them.\n> \n> -Peff\n\n$ GIT_TRACE=1 git status\ntrace: built-in: git 'status'\n# On branch master\n#\n# Initial commit\n#\ntrace: run_command: 'submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD'\ntrace: exec: 'git' 'submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD'\ntrace: exec: 'git-submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD'\ntrace: run_command: 'git-submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD'\ntrace: built-in: git 'rev-parse' '--git-dir'\ntrace: built-in: git 'rev-parse' '--show-cdup'\ntrace: built-in: git 'rev-parse' '-q' '--git-dir'\ntrace: built-in: git 'rev-parse' '--is-inside-work-tree'\ntrace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD^0'\nwarning: ignoring dangling symref HEAD.\ntrace: built-in: git 'rev-parse' '--show-toplevel'\ntrace: built-in: git 'diff-index' '--cached' '--raw' 'HEAD' '--' 'HEAD'\nfatal: bad revision 'HEAD'\ntrace: run_command: 'submodule' 'summary' '--files' '--for-status' '--summary-limit' '-1'\ntrace: exec: 'git' 'submodule' 'summary' '--files' '--for-status' '--summary-limit' '-1'\ntrace: exec: 'git-submodule' 'summary' '--files' '--for-status' '--summary-limit' '-1'\ntrace: run_command: 'git-submodule' 'summary' '--files' '--for-status' '--summary-limit' '-1'\ntrace: built-in: git 'rev-parse' '--git-dir'\ntrace: built-in: git 'rev-parse' '--show-cdup'\ntrace: built-in: git 'rev-parse' '-q' '--git-dir'\ntrace: built-in: git 'rev-parse' '--is-inside-work-tree'\ntrace: built-in: git 'rev-parse' '-q' '--verify' '^0'\ntrace: built-in: git 'rev-parse' '--show-toplevel'\ntrace: built-in: git 'diff-files' '--raw' '--'\nnothing to commit (create/copy files and use \"git add\" to track)\n\nI did build git myself, and \"make clean && make\" does exhibit the same\nbehavior. (Specifically: git checkout v1.7.0 && git clean -xfd && make\nclean && make)\n\nIt looks like this is all because I have status.submodulesummary = true\nin my ~/.gitconfig.\n\n-- \nJacob Helwig\n"},{"id":"134706","messageId":"20100216064753.GD2169@coredump.intra.peff.net","threadId":"22672","inReplyTo":"20100216062422.GC10296@vfb-9.home","subject":"Re: Fatal error running status in new repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-16T06:47:53Z","receivedAt":"2010-02-16T06:47:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 15, 2010 at 10:24:22PM -0800, Jacob Helwig wrote:\n\n> $ GIT_TRACE=1 git status\n> trace: built-in: git 'status'\n> # On branch master\n> #\n> # Initial commit\n> #\n> trace: run_command: 'submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD'\n\nAh, OK. That is why I did not see it; I don't have submodulesummary\nturned on.\n\nI can reproduce your problem. The messages are actually from two\ndifferent spots. The first is actually a bug in the code I mentioned\nearlier, and I'm still tracking down the second. Patches in a moment.\n\n-Peff\n"},{"id":"134708","messageId":"20100216070315.GE2169@coredump.intra.peff.net","threadId":"22672","inReplyTo":"20100216064753.GD2169@coredump.intra.peff.net","subject":"[PATCH] dwim_ref: fix dangling symref warning","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-16T07:03:16Z","receivedAt":"2010-02-16T07:03:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"If we encounter a symref that is dangling, in most cases we\nwill warn about it. The one exception is a dangling HEAD, as\nthat indicates a branch yet to be born.\n\nHowever, the check in dwim_ref was not quite right. If we\nwere fed something like \"HEAD^0\" we would try to resolve\n\"HEAD\", see that it is dangling, and then check whether the\n_original_ string we got was \"HEAD\" (which it wasn't in this\ncase). And that makes no sense; the dangling thing we found\nwas not \"HEAD^0\" but rather \"HEAD\".\n\nFixing this squelches a scary warning from \"submodule\nsummary HEAD\" (and consequently \"git status\" with\nstatus.submodulesummary set) in an empty repo, as the\nsubmodule script calls \"git rev-parse -q --verify HEAD^0\".\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n sha1_name.c |    3 +--\n 1 files changed, 1 insertions(+), 2 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 7729925..43884c6 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -280,8 +280,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)\n \t\t\t\t*ref = xstrdup(r);\n \t\t\tif (!warn_ambiguous_refs)\n \t\t\t\tbreak;\n-\t\t} else if ((flag & REF_ISSYMREF) &&\n-\t\t\t   (len != 4 || strcmp(str, \"HEAD\")))\n+\t\t} else if ((flag & REF_ISSYMREF) && strcmp(fullref, \"HEAD\"))\n \t\t\twarning(\"ignoring dangling symref %s.\", fullref);\n \t}\n \tfree(last_branch);\n-- \n1.7.0.25.g1cf14\n"},{"id":"134710","messageId":"20100216072154.GF2169@coredump.intra.peff.net","threadId":"22672","inReplyTo":"20100216062422.GC10296@vfb-9.home","subject":"Re: Fatal error running status in new repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-16T07:21:54Z","receivedAt":"2010-02-16T07:21:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 15, 2010 at 10:24:22PM -0800, Jacob Helwig wrote:\n\n[in an empty repo]\n> $ GIT_TRACE=1 git status\n> trace: built-in: git 'status'\n> # On branch master\n> #\n> # Initial commit\n> #\n[...]\n> trace: run_command: 'git-submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD'\n[...]\n> trace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD^0'\n> warning: ignoring dangling symref HEAD.\n[...]\n> trace: built-in: git 'diff-index' '--cached' '--raw' 'HEAD' '--' 'HEAD'\n> fatal: bad revision 'HEAD'\n\nThe patch I just posted elsewhere in the thread fixes the \"ignoring\ndangling symref\" message. The \"bad revision 'HEAD'\" comes from\ndiff-index. But as you can see, that diff-index invocation is somewhat\nbogus.\n\nIt looks like this code (git-submodule.sh:556-562):\n\n        if rev=$(git rev-parse -q --verify \"$1^0\")\n        then\n                head=$rev\n                shift\n        else\n                head=HEAD\n        fi\n\nis meant to guess whether the argument is a revision or a file limiter,\nand if the latter, assume HEAD was meant. Which obviously breaks down\nwhen the argument is HEAD and it is invalid. The patch below seems to\nfix it for me, but I have no idea if I am breaking something else.\n\nCan somebody more clueful about the submodule script take a look?\n\n-Peff\n\n---\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 664f217..4332992 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -555,10 +555,12 @@ cmd_summary() {\n \n \tif rev=$(git rev-parse -q --verify \"$1^0\")\n \tthen\n \t\thead=$rev\n \t\tshift\n+\telif test \"$1\" = \"HEAD\"; then\n+\t\treturn\n \telse\n \t\thead=HEAD\n \tfi\n \n \tif [ -n \"$files\" ]\n"},{"id":"134721","messageId":"201002161121.14613.johan@herland.net","threadId":"22672","inReplyTo":"20100216072154.GF2169@coredump.intra.peff.net","subject":"[PATCH] submodule summary: Don't barf when invoked in an empty repo","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2010-02-16T10:21:14Z","receivedAt":"2010-02-16T10:21:14Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"When invoking \"git submodule summary\" in an empty repo (which can be\nindirectly done by setting status.submodulesummary = true), it currently\nemits an error message (via \"git diff-index\") since HEAD points to an\nunborn branch.\n\nThis patch adds handling of the HEAD-points-to-unborn-branch special case,\nso that \"git submodule summary\" no longer emits this error message.\n\nThe patch also adds a test case that verifies the fix.\n\nSuggested-by: Jeff King <peff@peff.net>\nSigned-off-by: Johan Herland <johan@herland.net>\n---\n\nOn Tuesday 16 February 2010, Jeff King wrote:\n> It looks like this code (git-submodule.sh:556-562):\n> \n>         if rev=$(git rev-parse -q --verify \"$1^0\")\n>         then\n>                 head=$rev\n>                 shift\n>         else\n>                 head=HEAD\n>         fi\n> \n> is meant to guess whether the argument is a revision or a file limiter,\n> and if the latter, assume HEAD was meant. Which obviously breaks down\n> when the argument is HEAD and it is invalid. The patch below seems to\n> fix it for me, but I have no idea if I am breaking something else.\n> \n> Can somebody more clueful about the submodule script take a look?\n\nI don't know this code very well, but from looking at the commit introducing\nthis code (28f9af5: git-submodule summary: code framework), your analysis\nmakes sense. However, your fix doesn't work well for me.\n\n> ---\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 664f217..4332992 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -555,10 +555,12 @@ cmd_summary() {\n> \n>  \tif rev=$(git rev-parse -q --verify \"$1^0\")\n>  \tthen\n>  \t\thead=$rev\n>  \t\tshift\n> +\telif test \"$1\" = \"HEAD\"; then\n> +\t\treturn\n>  \telse\n>  \t\thead=HEAD\n>  \tfi\n> \n>  \tif [ -n \"$files\" ]\n\nI'm working from the simple test case in the below patch, I get the\nfollowing output with your proposed fix:\n\n  [...]\n  trace: built-in: git 'rev-parse' '-q' '--verify' '^0'\n  [...]\n  trace: built-in: git 'diff-index' '--raw' 'HEAD' '--'\n  fatal: bad revision 'HEAD'\n  [...]\n\nI.e. your fix doesn't work because $1 is empty (not \"HEAD\") at this point.\n\nMy alternative patch (below) does pass my test case (and all the other\ntests as well)\n\nI'd still like an ACK from the original author (Ping Yin) as well, as I'm\nnot sure if I overlooked something by removing the \"$1^0\".\n\n\nHave fun! :)\n\n...Johan\n\n\n git-submodule.sh             |    7 +++++--\n t/t7401-submodule-summary.sh |    7 +++++++\n 2 files changed, 12 insertions(+), 2 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 664f217..906b7b2 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -553,12 +553,15 @@ cmd_summary() {\n \n \ttest $summary_limit = 0 && return\n \n-\tif rev=$(git rev-parse -q --verify \"$1^0\")\n+\tif rev=$(git rev-parse -q --verify --default HEAD $1)\n \tthen\n \t\thead=$rev\n \t\tshift\n+\telif test -z \"$1\" -o \"$1\" = \"HEAD\"\n+\tthen\n+\t\treturn\n \telse\n-\t\thead=HEAD\n+\t\thead=\"HEAD\"\n \tfi\n \n \tif [ -n \"$files\" ]\ndiff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh\nindex d3c039f..cee319d 100755\n--- a/t/t7401-submodule-summary.sh\n+++ b/t/t7401-submodule-summary.sh\n@@ -227,4 +227,11 @@ test_expect_success 'fail when using --files together with --cached' \"\n     test_must_fail git submodule summary --files --cached\n \"\n \n+test_expect_success 'should not fail in an empty repo' \"\n+    git init xyzzy &&\n+    cd xyzzy &&\n+    git submodule summary >output 2>&1 &&\n+    test_cmp output /dev/null\n+\"\n+\n test_done\n-- \n1.7.0.rc1.141.gd3fd\n\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"134837","messageId":"20100217061005.GA520@coredump.intra.peff.net","threadId":"22672","inReplyTo":"201002161121.14613.johan@herland.net","subject":"Re: [PATCH] submodule summary: Don't barf when invoked in an empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-17T06:10:05Z","receivedAt":"2010-02-17T06:10:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 16, 2010 at 11:21:14AM +0100, Johan Herland wrote:\n\n> I'm working from the simple test case in the below patch, I get the\n> following output with your proposed fix:\n> \n>   [...]\n>   trace: built-in: git 'rev-parse' '-q' '--verify' '^0'\n>   [...]\n>   trace: built-in: git 'diff-index' '--raw' 'HEAD' '--'\n>   fatal: bad revision 'HEAD'\n>   [...]\n> \n> I.e. your fix doesn't work because $1 is empty (not \"HEAD\") at this point.\n\nAh, right. I was testing \"git status\" which calls \"git submodule summary\nHEAD\", but your test uses the assumed HEAD. And both need fixing.\n\n> My alternative patch (below) does pass my test case (and all the other\n> tests as well)\n> \n> I'd still like an ACK from the original author (Ping Yin) as well, as I'm\n> not sure if I overlooked something by removing the \"$1^0\".\n\nYour patch looks correct to me. I don't really see how dropping the \"^0\"\nwill have any effect. rev-parse --verify already prefers revisions to\nfiles, and diff-index should peel if needed.\n\nWhich, btw, seems like a mini-bug here. The point of this code is to say\n\"if we have an argument, is it a revision? If so, shift it off.\nOtherwise, put it (and any other arguments) after the -- as a file\nlimiter\".\n\nUsually if I have a branch \"master\" and a file \"master\", git will\ncomplain about the ambiguity unless I use an explicit \"--\" separator.\nBut here it always takes it as a revision, no questions asked. Or if I\nam in \"--files\" mode, that argument is simply removed and ignored (see\njust below where we unset $head).\n\nProbably it should be re-ordered as\n\n  if test -n \"$files\"; then\n     ...\n  else\n     if rev=$(git rev-parse -q --verify --default HEAD \"$1\")\n       ...\n  fi\n\nIt just doesn't come up much because usually having branch names and\nfilenames the same is sufficiently annoying that nobody does it.\n\n-Peff\n"}]}