Since when is a tag a commit?

Current `next`:

  [spearce@pb15 git]$ git cat-file commit v1.4.1
  tree 34c8f9c263c1c20592d3f56c3d86bea322577155
  parent 6631c73685bea3c6300938f4900db0d0c6bee457
  author Linus Torvalds <torvalds@osdl.org> 1151691633 -0700
  committer Junio C Hamano <junkio@cox.net> 1151803695 -0700
  ...

Uhhh, that's a tag.  I know it is:

  [spearce@pb15 git]$ git cat-file tag v1.4.1
  object 0556a11a0df6b4119e01aa77dfb795561e62eb34
  type commit
  tag v1.4.1
  tagger Junio C Hamano <junkio@cox.net> 1151818415 -0700
  ...

And I know its not a tree:

  [spearce@pb15 git]$ git cat-file tree v1.4.1
  100644 .gitignore{?MX~ă????y?v?X?u100644 COPYINGo?...

So it better not be a blob:

  [spearce@pb15 git]$ git cat-file blob v1.4.1
  fatal: git-cat-file v1.4.1: bad file

What the heck is going on? Since when did git cat-file happily consider a tag to be a tag, a commit and a tree? Its that intentional that we're peeling back the object to the requested type?

On Mon, 7 Aug 2006, Shawn Pearce wrote:

I think it's done that for a long time now. All of the other commands that take a tree or a commit will accept a tag, so why shouldn't "git cat-file tree"?

	-Daniel
*This .sig left intentionally blank*

Shawn Pearce wrote:

This is commit referenced by tag, i.e. v1.4.1^{commit}

This is tag itself.

This is tree referenced by commit, referenced by tag, i.e. v1.4.1^{tree}