"Jay Soffian" [off-list ref] 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.
Hi,
Junio C Hamano wrote:
"Jay Soffian" [off-list ref] writes:
quoted
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 [off-list ref], PGP 0x6EDDD207FCC5040F