Are these bugs?

Are these bugs?

[Jay Soffian]

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.

Re: Are these bugs?

[Junio C Hamano]

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

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

This is in "patches welcome" category.

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

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.

Re: Are these bugs?

[Stephan Beyer]

Hi,

Junio C Hamano wrote:
> "Jay Soffian" <jaysoffian@gmail.com> writes:
> 
> > I understand why "git reset" failed, but at best the error message is
> > confusing to a new user.
> 
> This is in "patches welcome" category.

<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>, PGP 0x6EDDD207FCC5040F

Re: Are these bugs?

[Junio C Hamano]

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

> Junio C Hamano wrote:
> 
>> "Jay Soffian" <jaysoffian@gmail.com> writes:
>> 
>> > I understand why "git reset" failed, but at best the error message is
>> > confusing to a new user.
>> 
>> This is in "patches welcome" category.
>
> <noise>
> But I still think it's stupid.
> </noise>

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.

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

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.

Re: Are these bugs?

[Benny Halevy]

On Aug. 28, 2008, 4:20 +0300, Junio C Hamano <gitster@pobox.com> wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
> 
>> Junio C Hamano wrote:
>>
>>> "Jay Soffian" <jaysoffian@gmail.com> writes:
>>>
>>>> I understand why "git reset" failed, but at best the error message is
>>>> confusing to a new user.
>>> This is in "patches welcome" category.
>> <noise>
>> But I still think it's stupid.
>> </noise>
> 
> 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.
> 
>> So, for a patch, is it sane to just remove/clear the index
>> if get_sha1("HEAD", sha1) fails?
> 
> 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.

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

> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Are these bugs?

[Jay Soffian]

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:
> "Jay Soffian" <jaysoffian@gmail.com> writes:
>
>> I understand why "git reset" failed, but at best the error message is
>> confusing to a new user.
>
> This is in "patches welcome" category.

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

>> 2. "git add --ignore-errors" doesn't work with ignored files:
>>
>> $ git add --ignore-errors foo bar
>
> 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.

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.