Thanks for the explanation.

I actually do not have any clear opinion what it should do. Just that the current situation is confusing when experimenting and trying to understand the behavior of git blame and git log: an intuitive option that is accepted but ignored.

The option should either be rejected or do *something* documented and useful. Ideally, it should result in behavior that matches 'git log --follow' as closely as possible. So maybe, it should be a synonym for a certain number of "-C" options?


Am 06.09.12 11:58, schrieb Jeff King:
On Thu, Sep 06, 2012 at 09:02:17AM +0200, norbert.nemec wrote:

'git blame --follow' seems to be undocumented. The exact behavior is
not clear to me. Perhaps an alias for some combination of '-C' and
'-M'? It seems not be be fully consistent with 'git log --follow'.

Could someone clarify? Did I miss something?

I don't think it was ever intended to do anything; the only reason it is
not rejected outright is that "blame" piggy-backs on the regular
revision option parser used by "log" and others.

What would you expect it to do?

I can't think of a sane behavior for "blame --follow". The follow code
is about tweaking path-limiting during traversal, but blame does not use
pathspecs. It tracks content, and the "-C" option already instructs it to
look across file boundaries.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to