git-add fails after file type change

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.

Jakub Narebski wrote:

Works if you use "git mv dir dir.real".
  

This came up during my testing of snapshot backups. The *real* sequence 
is more like

$ git checkout -b new-snapshot
$ rsync /live/directory .
$ git add .

In other words, I don't know in advance that there's a rename or (short 
of turning on verbose rsync output and parsing it) which parts of the 
tree have changed at all. So I can't easily use git-mv here.

It still feels like a bug that "git add" can fail with no useful 
diagnostic. It actually took me a fair while to figure out what was 
going on here -- at first I thought it was having trouble with symlinks 
in general, then with absolute-path symlinks (which the actual symlink 
in question is), then I thought maybe it was a corrupt index. It wasn't 
until I went back and looked at the previous snapshot that I was 
overlaying this one on top of that I realized there used to be a 
directory where that symlink lives now.

Steven Grimm wrote:

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

Works if you use "git mv dir dir.real".

$ 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
$ git mv dir dir.real
$ ln -s dir.real dir
$ git add .
$ git commit -m "second commit" -a
$ git ls-tree HEAD
120000 blob e05f72eddb14362b836c3612c13d441b097a065a    dir
040000 tree 4a1c03029e7407c0afe9fc0320b3258e188b115e    dir.real
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Steven Grimm wrote:

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.

A Large Angry SCM wrote:

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

Turns out that doesn't work. It gives me the same error I get without 
the --replace option:

error: dir: cannot add to the index - missing --add option?
fatal: Unable to process file dir

However, "git rm" followed by "git add" does seem to work. So for now it 
looks like that'll be the best bet when I run into this problem (should 
be possible to automate it, even.) The better error message from Junio's 
patch will at least make the failure less mysterious.

IMO it'd still be nice if the porcelain could provide a "make the index 
look like the working directory" operation that worked even in the face 
of changes like this, adding and/or removing files as needed. But it's 
possible that my crazy git-as-backup-device setup is the only place 
where this is even an issue; typical git users can use "git mv" and 
never run into the problem.

-Steve