Re: What should "git submodule summary" give before an initial commit?

From: Sverre Rabbelier <srabbelier@gmail.com>
Date: Mar 4, 2010, 06:01 UTC
Message-ID: <fabb9a1e1003032201l38b052ebk4c0061e9d40f68b6@mail.gmail.com>
In-Reply-To: <4B8F00AA.5050007@web.de>

Heya,

On Thu, Mar 4, 2010 at 01:36, Jens Lehmann <Jens.Lehmann@web.de> wrote:

> But to make "git status" with status.submodulesummary work as expected,
> i need something like the following patch on top of current pu (because
> "git submodule summary --cached HEAD" returns no changes in a freshly
> created repo):

I think the problem is deeper than that: git doesn't work that great if there's no HEAD yet. Some of our features don't work (as expected) if there's no HEAD. For example, 'git reset' doesn't work, of course, I can use 'git rm --cached .' to achieve the same effect (since all staged changes are guaranteed to be adds), but its' not quite the same. Perhaps it's an idea to look at how we handle not having a head across the board and deal with it at a higher level? Something like pretending we do have a HEAD that's pointing at the empty tree when on an unborn branch might fix 'git reset' (although I'm sure there's all kinds of objections to actually doing that, I'm not suggesting that's what we should do, but that's the kind of solution I think we should look at).

-- 
Cheers,

Sverre Rabbelier