Are these bugs?

1. You can't use reset in a just initialized repo:

$ mkdir testrepo $ cd testrepo $ echo foo > foo $ git init $ git add . $ git reset fatal: Failed to resolve 'HEAD' as a valid ref.

In the real-world, I had initialized a new repository and realized I'd staged extra files I didn't want. I was going to "git reset" then re-add the specific files I wanted, but that obviously failed. I worked around this by using "git rm --cached" to get rid of what I didn't want.

I understand why "git reset" failed, but at best the error message is confusing to a new user.

2. "git add --ignore-errors" doesn't work with ignored files:

$ mkdir testrepo $ cd testrepo $ git init Initialized empty Git repository in /Users/jay/testrepo/.git/ $ echo foo >> .git/info/exclude $ echo foo > foo $ echo bar > bar $ git add --ignore-errors foo bar The following paths are ignored by one of your .gitignore files: foo Use -f if you really want to add them. fatal: no files added

Now you may ask "why are you specifying foo if you don't want to add
it?" In the real-world I was generating the list to "git add" with
xargs and it was quite a long list. It was easiest to filter out what
I didn't want through .git/info/exclude. But I ended up having to "...
| grep -v <stuff I don't want> | xargs git add".

So I think preferable would be: "Use -f if you really want to add them or --ignore errors to continue anyway."

$ git version git version 1.6.0.176.g8698c

Thoughts?

j.

"Jay Soffian" <jaysoffian@gmail.com> writes:

This is in "patches welcome" category.

The option, IIRC, is more about filesystem errors (failure to read), not about safety against user errors (specifying otherwise ignored paths).

If you are automating something that uses xargs to drive addition to the index, and the feeder to xargs knows better than .gitignore files, then probably your script should be using '-f' unconditionally. So I do not see why you would think #2 could be a bug.

Hi,

Junio C Hamano wrote:

<noise> I sometimes wondered if "git init" should create a dummy commit with empty tree, empty commit message or something like that and set refs/heads/master to that and HEAD to master. But I always said to myself that this is a stupid idea for several reasons, i.e. backwards compatibility, or: if the dummy commit is to be ignored (i.e. will not become parent of the first commit), then it does not really help at all in decreasing complexity. So I rejected this thought, but now it came back. ;-)

A backwards-compatibily-breaking dummy commit would also help rebasing onto the dummy (replacing the first real commit). But I still think it's stupid. </noise>

So, for a patch, is it sane to just remove/clear the index if get_sha1("HEAD", sha1) fails?

Regards,
  Stephan

Stephan Beyer <s-beyer@gmx.net> writes:

Yes I think it is stupid. The dummy commit does not change the fact that you need to special case it anyway, and special casing you can do without the dummy commit that will contaminate the history. We already have such special case for "log -p" (--root used to be optional). If rebasing onto emptiness is problematic, the command should be taught how.

As a general idea, yes, but details matter.

If the user says "git reset [--hard/--soft/--mixed] HEAD" from the command line, we should say "You do not even have HEAD commit". If "git reset" deduced (incorrectly) that the user meant HEAD, and only in that case, we should clear the index.

On Aug. 28, 2008, 4:20 +0300, Junio C Hamano <gitster@pobox.com> wrote:

I'm really not sure about the details, but providing a way to refer to the empty state of the tree is needed. For example, I don't know how to do an interactive rebase of all commits in my tree, or to rebase a sub-series starting at "INIT" (or "NIL" or whatever :) onto some other base (say some remote branch).

Benny

Oops, should've gone to list.

---------- Forwarded message ----------
From: Jay Soffian <jaysoffian@gmail.com>
Date: Wed, Aug 27, 2008 at 9:25 PM
Subject: Re: Are these bugs?
To: Junio C Hamano <gitster@pobox.com>

On Wed, Aug 27, 2008 at 7:47 PM, Junio C Hamano <gitster@pobox.com> wrote:

Okay, good to know. I'll add it to me "things to do in spare time" list.

Well that's just it, my feeder to xargs did *not* know better than the .gitignore files so -f would have done the exact opposite of what I wanted. The git-add man page's description of --ignore-errors agrees with what you write above though, so I'll just move along on this one.

j.