Re: [PATCH] fsck: warn about '.' and '..' in trees

From: Jeff King <peff@peff.net>
Date: Nov 28, 2012, 04:32 UTC
Message-ID: <20121128043215.GA5362@sigill.intra.peff.net>
In-Reply-To: <CACsJy8DQCo9UzDadHJ2dF-eK20tFDTVn_ScwV+T7z-qLDJMytw@mail.gmail.com>

On Wed, Nov 28, 2012 at 11:22:20AM +0700, Nguyen Thai Ngoc Duy wrote:

Show 12 quoted lines

> > 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