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.
-Steve
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html