`Index.add()` accepts files behind symlinks

まず、最後のコンポーネントではない symlink コンポーネントを含む場合の Index.add() の報告された動作を再現し、同じパスを git-add が拒否する場合と比較します。Index.add_all() と IndexEntry も同様に動作するか確認し、対応する libgit2 の動作を調査します。期待される処理が確立され、回帰テストでカバーされていれば完了です。

Hey.

Not sure whether this is a bug or considered valid (though probably strange) usage, but Index.add() - and presumably Index.add_all() as well as IndexEntry, too - accept paths where even non-final components are symbolic links, like in symlink-to-dir/some-non-dir-file.

git-add itself rejects these with an error like:

$ git add symlink-to-dir/some-non-dir-file
fatal: pathspec 'symlink-to-dir/some-non-dir-file' is beyond a symbolic link

The Index object even uses these pathnames and doesn't just resolve them:

list(r.index)
[<pygit2.index.IndexEntry path=symlink-to-dir/some-non-dir-file id=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 mode=33188>]

Creating a commit of that works, too.

Now the problem with such pathnames is that symlink-to-dir is not added as a symbolic link to the index (at least not automatically), instead it seems to behave as if there were a true directory of that name which contained the file, but which is then immediately gone after adding.

IMO hat leads to all kinds of unexpected stuff (which is probably the reason why git-add forbids it instead of e.g either resolving it or doing something else (like resolving it and adding the file under its real dir).

Maybe pygit2 should also reject these? Not sure what libgit2 does, though.

Cheers,
Chris.