On May 7, Junio C Hamano wrote:
> Eli Barzilay <eli@xxxxxxxxxxxx> writes:
>
> > So if there was some single
> >
> > --do-whatever-you-can-as-much-as-you-can-to-find-all-renames
>
> If I am not mistaken, that is exactly the point of Bo's patch:
>
> Message-Id: <1273207949-18500-4-git-send-email-struggleyb.nku@xxxxxxxxx>
(Actually, I was talking about some meta option that always turns on
whatever can be done to track copies; but given the clarification from
Jeff below, it's not as important as I first thought.)
On May 8, Jeff King wrote:
> On Sat, May 08, 2010 at 01:12:58AM -0400, Eli Barzilay wrote:
>
> > > > BTW, I've had at least 4 people now who got confused by this. Is
> > > > there any use for -M/-C without --follow? In any case, it will be
> > > > very helpful if the -M/-C descriptions said "see also --follow".
> > >
> > > Yes, it detects renames when doing diffs.
> >
> > OK, so just to clear this up: -C and -M (and --find-copies-harder)
> > are for `diff', and --follow is for `log' with a single file (and
> > each will pass it on to the other)?
>
> Yes (well, diff can never pass --follow to log, since diff never
> invokes log, but yes, the per-commit diff shown by log uses the -C
> and -M given to log).
Aha -- I now see what makes most of this confusion, and an easy way to
improve it considerably: looking at the `git-log' man page, I have to
wade through 11 pages of general diff options (well, 11 is so high
because I like big fonts in my emacs...) before I get to the log
options, and even worse, there is no clear indication that those
options are only relevant if I want to get patches, which is (at least
in my interactive use cases) far from being something I do often.
(Googling around, I see more than a few examples of confused uses of
`git log -M', even the git faq says "'git log -M' will give the commit
history with rename information" -- no mention of it not making any
sense with a file that went through a rename.)
So I think that it would really help if (1) the diff options in the
git-log man page move to after its own options, and (2) they appeared
after a title saying that these are the diff options, (3) `--follow'
moves up before the few preceding options that seem to me less
important. To clarify, I added a simple patch to the end of this
message. (`git-format-patch' has the same thing, but there it looks
more sensible to leave it as is.)
> > So if there was some single
> >
> > --do-whatever-you-can-as-much-as-you-can-to-find-all-renames
>
> But I think all you really wanted was "--follow". I'd have to check the
> code, but I'm not even sure whether "-C" will impact --follow at all.
If -C/-M are really only affecting the patches, then yes, I'd probably
be happy with only `--follow' (or a way to have --follow on by default
when possible).
> No, copy detection can be _really_ slow. There is a reason it isn't
> on by default. Try "git log -1000 -p" versus "git log -1000 -p -C -M
> --find-copies-harder" in some repository. In a simple git.git test,
> it is almost 5x slower (about 1 second versus 5 seconds on my
> machine). For large repositories, it can be much worse, because now
> each diff is O(size of repository) instead of O(size of changes).
Yes, I see that. I was talking about interactive uses, where I'd
never want to see a 1000 diffs, or even 2. But given that -C/-M are
only for patches, then I agree with that.
> Still, I see your point that you might want it on all the time, if you
> have a sufficiently small repo. There is "diff.renames" to turn on
> rename detection all the time.
(Ah, I missed that...)
> But I think a log.follow option doesn't make sense at this
> point. For example:
>
> $ git config log.follow true
> $ git log foo.c ;# ok, follow foo.c
> $ git log foo.c bar.c ;# uh oh, now what?
>
> Does the last one just barf, and make you say "git log --no-follow
> foo.c bar.c"? Does it quietly turn off --follow, making the user
> guess why "git log foo.c" finds some history that "git log foo.c
> bar.c" doesn't?
How about these options:
git config log.follow if-single-file
makes it use --follow only when there's a single file path given,
ignoring it otherwise (with no confusion about it now)
git config log.follow if-possible
makes it do the same, but might also do it for more cases if/when
they become available (so this is the "do the best you can"
option)
git config log.follow true
invalid until it is always possible to use --follow
?
[this is the patch that I mentioned above]
-------------------------------------------------------------------------------
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index fb184ba..6bc7064 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -24,7 +24,6 @@ OPTIONS
-------
:git-log: 1
-include::diff-options.txt[]
-<n>::
Limits the number of commits to show.
@@ -37,6 +36,10 @@ include::diff-options.txt[]
and <until>, see "SPECIFYING REVISIONS" section in
linkgit:git-rev-parse[1].
+--follow::
+ Continue listing the history of a file beyond renames
+ (works only for a single file).
+
--decorate[=short|full]::
Print out the ref names of any commits that are shown. If 'short' is
specified, the ref name prefixes 'refs/heads/', 'refs/tags/' and
@@ -55,9 +58,6 @@ include::diff-options.txt[]
the specified paths; this means that "<path>..." limits only
commits, and doesn't limit diff for those commits.
---follow::
- Continue listing the history of a file beyond renames.
-
--log-size::
Before the log message print out its size in bytes. Intended
mainly for porcelain tools consumption. If git is unable to
@@ -71,6 +71,10 @@ include::diff-options.txt[]
to be prefixed with "\-- " to separate them from options or
refnames.
+Common diff options
+~~~~~~~~~~~~~~~~~~~
+
+include::diff-options.txt[]
include::rev-list-options.txt[]
-------------------------------------------------------------------------------
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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