Re: [doc] User Manual Suggestion

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Apr 27, 2009, 00:00 UTC
Message-ID: <20090427000007.GE12338@atjola.homenet>
In-Reply-To: <b4087cc50904241629u76454b1chc6e84e95066a9100@mail.gmail.com>

On 2009.04.24 18:29:22 -0500, Michael Witten wrote:

Show 7 quoted lines

> On Fri, Apr 24, 2009 at 18:21, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > "git blame 1a2b3c:Makefile" worked despite this technically being
> > incoherent.
> 
> It seems to work on my end, and it's perfectly coherent if you
> consider git-blame to be overloaded to handle both pointers and
> addresses (or references and object names, if you prefer).

Fails for me. And it's technically incoherent in that it makes no sense to use blame with a blob object. 1a2b3c:Makefile identifies "just" a blob object. And that has no parents and no history, just contents. Only the commit objects have the references that connect them to form a history.

For example, you could have a history like this:

A---B---C---D---E

And a file "foo" that has the same contents for A and E. Then "A:foo" and "E:foo" lead to the same blob object, and you can't uniquely go from that blob object to any commit object. So technically, you can't tell if "git blame E:foo" means "git blame E foo" or "git blame A foo" (and you can add a bunch of complexity by having, for example, a second file with a different name that had the same content at some point).

To make that coherent, you must change the definition of the <tree-ish>:<path> syntax so that the context in which the path is resolved is kept, it must no longer just identify an object, but something more complex.

Björn