git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Helwig <jacob.helwig@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Fatal error running status in new repo
Date: Mon, 15 Feb 2010 22:24:22 -0800	[thread overview]
Message-ID: <20100216062422.GC10296@vfb-9.home> (raw)
In-Reply-To: <20100216060528.GB2169@coredump.intra.peff.net>

On 01:05 Tue 16 Feb     , Jeff King wrote:
> 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

  reply	other threads:[~2010-02-16  6:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16  4:19 Fatal error running status in new repo Jacob Helwig
2010-02-16  6:05 ` Jeff King
2010-02-16  6:24   ` Jacob Helwig [this message]
2010-02-16  6:47     ` Jeff King
2010-02-16  7:03       ` [PATCH] dwim_ref: fix dangling symref warning Jeff King
2010-02-16  7:21     ` Fatal error running status in new repo Jeff King
2010-02-16 10:21       ` [PATCH] submodule summary: Don't barf when invoked in an empty repo Johan Herland
2010-02-17  6:10         ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100216062422.GC10296@vfb-9.home \
    --to=jacob.helwig@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).