Re: [PATCH 3/3] git-add --intent-to-add (-N)

On Thu, 21 Aug 2008, Jonathan Nieder wrote:

Hi,

Jonathan Nieder wrote:

quoted

I quite like the idea of this patch series.  When I try to test it with
"git merge jc/ita; make test", t0020-crlf setup fails

[...]

quoted

This could be me doing something [stupid]

and it was.  In a sleepy daze, I resolved a conflict

<<<<<<<
#define ADD_CACHE_IGNORE_REMOVAL 8
=======
#define ADD_CACHE_INTENT 8

quoted

quoted

quoted

quoted

quoted

quoted

quoted

by using the same bit for both.  Sorry for the noise.

Others can experience that unpleasant error message for themselves
with next + jc/add-ita merged properly:

	$ mkdir test-repo && cd test-repo
	$ git init
	Initialized empty Git repository in /var/tmp/jrnieder/test-repo/.git/
	$ : >a
	$ git add -N a
	$ git commit
	error: invalid object e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
	error: Error building trees

I think the first error comes from update_one, which creates a tree
object from the index.  It is complaining, because after all, that
object is not in any sha1 file.

I think [1/3] was supposed to make this not an issue, with that particular 
object being implicitly in all objects databases.

If the empty blob happened to be in our object database, the user's
mistake would be hidden:

	$ git add a && git commit
	error: invalid object e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
	error: Error building trees
	$ git rm -f --cached a
	rm 'a'
	$ git add a
	$ git commit -m initial
	$ echo hi >b
	$ git add -N b
	$ git commit && echo ok
	Created commit 91325db: some commit message
	 0 files changed, 0 insertions(+), 0 deletions(-)
	 create mode 100644 b
	ok

Maybe it would be better to use some other magic blob (or a bit
somewhere) to remember that the file has not been added yet.

An actual magic value (maybe the all-zeros hash) would make it an actual 
error for the file to not have been added; the current code behaves as if 
you did:

$ touch b
$ git add b

right before putting anything in b. Aside, perhaps, from retrieval bugs, 
it's just like you actually added an empty blob.

Last time I tried something along these lines, using the all-zeros hash 
actually came pretty close to working, except that diff uses this value 
for "look at the working tree" in its representation, and stuff gets 
confused by it; these are actually distinguishable, IIRC, by whether the 
mode bits are set or not, but current code doesn't check that.

	-Daniel
*This .sig left intentionally blank*