On Tue, Nov 29, 2011 at 07:25:47PM +0100, Ralf Thielow wrote:
> Why is the option "--follow" not the default if the log-command
> is used with a single file? Many GUI tools don't show me the
> full history of a single file if there was a rename in it.
A few reasons, I think:
1. There is no such thing as giving log a single file. You give it a
pathspec. That may happen to match a single file in the current
revision, but to git it is actually a prefix-limiting pattern, and
"git log foo" will match "foo" if it is a file, or "foo/bar" if it
was a directory in a previous revision.
2. It can be slower than a regular traversal, since we have to do
rename detection whenever we see a deletion. In practice I don't
think it is much slower, though (mainly because files don't get
moved all that much).
3. The implementation is a bit hacky. In particular, things like
history simplification and parent rewriting won't work. So a
GUI tool that tries to draw a graph will make a very ugly graph.
Try looking at "gitk $file" and then "gitk --follow $file" in some
repository (if you don't have gitk, try "git log --graph
--oneline"). Even with a linear history, things look ugly: there
are big gaps in the graph. But in a branch-y history, it's
downright unreadable, as you have parallel disconnected lines of
history next to each other.
I think (1) and (3) are fixable by improving the implementation (making
--follow respect pathspecs and not single files, and having it work at
the history-simplification level). And then you might argue that (2)
isn't a big deal, and we can turn on --follow all the time.
-Peff
--
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