Re: git-add fails after file type change

A Large Angry SCM [off-list ref] writes:

Steven Grimm wrote:

quoted

In the course of experimenting with using git for my snapshot
backups, I ran into what looks like a bug in git-add: it croaks when
it tries to add a file whose type has changed, specifically when a
directory gets moved and a symbolic link is put in the old location
pointing to the new one. Here's a simple test case:

$ git init-db
defaulting to local storage area
$ mkdir dir
$ echo foo > dir/file
$ git add .
$ git commit -m "initial commit" -a
Committing initial tree f4bc9c50d08b041f5e096fa68e243c34170f1cd8
create mode 100644 dir/file
$ mv dir dir.real
$ ln -s dir.real dir
$ git add .
fatal: unable to add dir to index

Is "git add ." the wrong thing to do here? I have been using it as a
generic "pick up all the files I haven't added yet" command. Or is
this a bug?

For what it's worth, "git update-index dir" and "git update-index
--add dir" both fail too.

Did you try "git-update-index --replace dir"?

Good point.  I've forgotten about "--replace" codepath, although
that is all my code (May 7, 2005).

Maybe "git add" should internally use ADD_CACHE_OK_TO_REPLACE
(or error out and have an option to enable it)?

In any case, the error message could be made a bit more helpful,
like this.

---

diff --git a/read-cache.c b/read-cache.c
index eae4745..a602010 100644
--- a/read-cache.c
+++ b/read-cache.c

@@ -609,7 +609,7 @@ int add_cache_entry(struct cache_entry *ce, int option)
 	if (!skip_df_check &&
 	    check_file_directory_conflict(ce, pos, ok_to_replace)) {
 		if (!ok_to_replace)
-			return -1;
+			return error("'%s' appears as both a file and as a directory", ce->name);
 		pos = cache_name_pos(ce->name, ntohs(ce->ce_flags));
 		pos = -pos-1;
 	}

Junio C Hamano wrote:

Maybe "git add" should internally use ADD_CACHE_OK_TO_REPLACE
(or error out and have an option to enable it)?
  

That sounds right to me. Maybe there are cases where this isn't true, 
but -- especially given the recent move toward making "git add" the 
suggested porcelain command for updating the index -- I want "git add 
foo" to stick the current contents of "foo" into the index, regardless 
of what might have been there under that name previously. I'll grant 
that it's not a super-common use case to rename or delete a directory 
and put a file in its place, but it's IMO not an unreasonable thing to 
want git to track without undue hassle, given that it claims to support 
renames. I'm fine with having to supply an extra option to get that 
automatic behavior.

But barring that, the patch would at least have saved me a lot of 
head-scratching.

-Steve