git blame --follow
Hi there, '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? Greetings, Norbert -- 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
Re: git blame --follow
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
Re: git blame --follow
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
Re: git blame --follow
On Thu, Sep 06, 2012 at 12:12:42PM +0200, norbert.nemec wrote: 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? But I don't see how it would match git log --follow, as that is a fundamentally different operation that makes no sense in the context of blame (why would you be adjusting the pathspec? There is no pathspec). A synonym for -C would just confuse things more, as log also has -C and it is not a synonym there. So if anything, I'd say to simply reject it. It's not documented, and it never did anything useful. Patches welcome. -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
