From: Jeff King <peff@peff.net>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] fsck: warn about '.' and '..' in trees
Date: Tue, 27 Nov 2012 23:32:16 -0500 [thread overview]
Message-ID: <20121128043215.GA5362@sigill.intra.peff.net> (raw)
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:
> > 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
next prev parent reply other threads:[~2012-11-28 4:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-28 2:27 [PATCH] fsck: warn about '.' and '..' in trees Jeff King
2012-11-28 4:22 ` Nguyen Thai Ngoc Duy
2012-11-28 4:32 ` Jeff King [this message]
2012-11-28 4:34 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121128043215.GA5362@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).