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?
Greetings,
Norbert
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.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
