On Dec 11, 2007, at 10:40 AM, Linus Torvalds wrote:
To git, "git annotate" is just about the *last* thing you ever want
to do.
It's not a common operation, it's a "last resort" operation. In git,
the
whole workflow is designed for "git log -p <pathnamepattern>" rather
than
annotate/blame.
My use of "git blame" is perhaps not typical, but I use it fairly
often when I'm looking at a part of my company's code base that I'm
not terribly familiar with. I've found it's the fastest way to figure
out who to go ask about a particular block of code that I think is
responsible for a bug, or more commonly, who to ask to review a change
I'm making.
"git log" is too coarse-grained to be useful for that purpose; it
usually doesn't tell me which of the 500 revisions to the file I'm
looking at introduced the actual line of code I want to change.
To me that really has nothing whatsoever to do with git workflow or
svn workflow; it happens well before I'm ready to do any kind of
integration or commit or even, sometimes, before I've made any changes
to any code at all.
Given infinite spare time, one of the things I'd be strongly tempted
to try to build would be some kind of blame cache. You could
theoretically make blame pretty much instantaneous by doing something
as simple as caching the per-line revision ID for each file in each
revision in a shadow repository (or a shadow branch in the main repo)
and keeping a map between shadow-repo revisions and real-repo ones. If
the cache was of the form "one SHA1 hash per line in the original
file" it would delta-compress pretty well. It'd be easy to update
incrementally since you only need to walk back in history until you
get to the most recently cached revision for each file, at which point
you use the cached value for all the lines that haven't changed.
Yeah, I know, code talks louder than words...
-Steve
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
