On Wed, Nov 28, 2012 at 11:22:20AM +0700, Nguyen Thai Ngoc Duy wrote:
> > I don't think this is happening in the wild, but I did see somebody
> > playing around with libgit2 make such a tree (and it is easy to do with
> > git-mktree, of course).
> >
> > Technically one could use git with such a tree as long as you never ever
> > checked out the result, but I think it is sufficiently crazy that we
> > should probably detect it, just in case.
>
> Can we declare "." and ".." illegal? There's no room for extension in
> tree objects and I'm thinking of using maybe "." entry as an extension
> indicator. Not sure if it works, old gits may attempt to checkout "."
> entries and fail...
Yeah, current git fails pretty hard. Try this:
check() {
git init -q "$1" &&
(cd "$1" &&
blob=$(echo foo | git hash-object -w --stdin) &&
tree=$(printf '100644 blob %s\t%s' $blob "$2" | git mktree) &&
commit=$(echo foo | git commit-tree $tree) &&
git update-ref HEAD $commit &&
git clone -q . clone
)
}
$ check dot .
error: Invalid path '.'
$ check dotdot ..
error: Updating '..' would lose untracked files in it
$ check dotgit .git
error: Updating '.git' would lose untracked files in it
Interesting that we detect the first one while reading into the cache,
but apparently try much harder to checkout on the latter two. Not sure I
want to try "git checkout -f". :)
-Peff
--
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