Re: Fatal error running status in new repo

From: Jacob Helwig <jacob.helwig@gmail.com>
Date: Feb 16, 2010, 06:24 UTC
Message-ID: <20100216062422.GC10296@vfb-9.home>
In-Reply-To: <20100216060528.GB2169@coredump.intra.peff.net>

On 01:05 Tue 16 Feb     , Jeff King wrote:

Show 53 quoted lines

> On Mon, Feb 15, 2010 at 08:19:45PM -0800, Jacob Helwig wrote:
> 
> > I just noticed this when creating a new repo for a project.
> > 
> > $ mkdir tmp
> > $ cd tmp
> > $ git init
> > Initialized empty shared Git repository in /home/jhe/projects/tmp/.git/
> > $ git status
> > # On branch master
> > #
> > # Initial commit
> > #
> > warning: ignoring dangling symref HEAD.
> > fatal: bad revision 'HEAD'
> > nothing to commit (create/copy files and use "git add" to track)
> > $ echo $?
> > 0
> > $ git --version
> > git version 1.7.0
> 
> I can't reproduce it here:
> 
>   $ mkdir tmp && cd tmp && git init && git status
>   Initialized empty Git repository in /home/peff/tmp/.git/
>   # On branch master
>   #
>   # Initial commit
>   #
>   nothing to commit (create/copy files and use "git add" to track)
> 
> Furthermore, the "ignoring dangling symref" message can only come from
> one place (sha1_name.c:285), and is specifically protected by a
> conditional making sure that the refname is not "HEAD". Which is just
> plain weird.
> 
> Do you have anything strange in your ~/.gitconfig? Can you try running
> with GIT_TRACE=1 to make sure we are not invoking some sub-command or
> something? Did you build git yourself? Can you double-check with a "make
> clean && make" that a newly built version exhibits the problem?
> 
> > Seems a bit silly that "git status" should be issuing warnings, and
> > fatal errors (especially when the exit code is still 0), when run before
> > the first commit has been created in a brand new repository.
> > 
> > The warnings make sense if you know what's going on behind the scenes,
> > but seem like the kind of thing that could scare someone new to git when
> > they haven't actually done anything wrong at this point.
> 
> Agreed. These warnings absolutely should not be shown, but I don't
> really understand what is showing them.
> 
> -Peff

$ GIT_TRACE=1 git status trace: built-in: git 'status' # On branch master # # Initial commit # trace: run_command: 'submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD' trace: exec: 'git' 'submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD' trace: exec: 'git-submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD' trace: run_command: 'git-submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD' trace: built-in: git 'rev-parse' '--git-dir' trace: built-in: git 'rev-parse' '--show-cdup' trace: built-in: git 'rev-parse' '-q' '--git-dir' trace: built-in: git 'rev-parse' '--is-inside-work-tree' trace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD^0' warning: ignoring dangling symref HEAD. trace: built-in: git 'rev-parse' '--show-toplevel' trace: built-in: git 'diff-index' '--cached' '--raw' 'HEAD' '--' 'HEAD' fatal: bad revision 'HEAD' trace: run_command: 'submodule' 'summary' '--files' '--for-status' '--summary-limit' '-1' trace: exec: 'git' 'submodule' 'summary' '--files' '--for-status' '--summary-limit' '-1' trace: exec: 'git-submodule' 'summary' '--files' '--for-status' '--summary-limit' '-1' trace: run_command: 'git-submodule' 'summary' '--files' '--for-status' '--summary-limit' '-1' trace: built-in: git 'rev-parse' '--git-dir' trace: built-in: git 'rev-parse' '--show-cdup' trace: built-in: git 'rev-parse' '-q' '--git-dir' trace: built-in: git 'rev-parse' '--is-inside-work-tree' trace: built-in: git 'rev-parse' '-q' '--verify' '^0' trace: built-in: git 'rev-parse' '--show-toplevel' trace: built-in: git 'diff-files' '--raw' '--' nothing to commit (create/copy files and use "git add" to track)

I did build git myself, and "make clean && make" does exhibit the same behavior. (Specifically: git checkout v1.7.0 && git clean -xfd && make clean && make)

It looks like this is all because I have status.submodulesummary = true in my ~/.gitconfig.

-- 
Jacob Helwig