On Fri, Mar 21, 2014 at 3:53 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Chris Angelico <rosuav@xxxxxxxxx> writes:
>
>> file. It doesn't really care about the full history, and wants to be
>> reasonably fast (as the user is waiting for it). It's just a
>> convenience, so correctness isn't a huge issue. The easiest way to
>> keep it moving through quickly is to limit the search:
>>
>> $ git log ...other options... HEAD~100 some-file.pike
>>
>> The problem with this is that it doesn't work if HEAD doesn't have 100
>> great-great-...-grandparents
>
> Did you really mean that you are *not* interested in what happened
> to the most recent 100 commits? Or is it a typo of "HEAD~100.."?
Oops, yes, HEAD~100.. is what I actually use in the source code. Same
difference; it doesn't work if there aren't that many commits.
> "git log -100" should traverse from the HEAD and stop after showing
> at most 100 items, even if you only had 20 in the history.
Yes, and I use that to limit the results (to 10, actually); but
there's one degenerate case left, and that's a new or moved/renamed
file in a long-standing repository. Let's say the repo has 760 commits
(which is currently the case for Gypsum; I'd say this is fairly small
as repos go), and a file was moved a little while ago and then not
edited much.
$ git log plugins-more/threshtime.pike
Four results, the oldest being "Move three plugins into -more" which
moved the file without any edits at all. If I edit that file now, the
prepare-commit-msg hook will execute the following (or would, if I
hadn't set the config option):
$ git log --shortstat --full-diff -10 --oneline plugins-more/threshtime.pike
fca89fe Threshtime: Drop a comment from the old C++ plugin
1 file changed, 1 insertion(+), 1 deletion(-)
df8bcf0 Threshtime: Make use of statusevent
1 file changed, 2 insertions(+), 11 deletions(-)
1207213 Threshtime: Use the tooltip to hint at the converter
1 file changed, 1 insertion(+)
c22dfbc Move three plugins into -more so they're loaded by default but
unloadable
6 files changed, 426 insertions(+), 426 deletions(-)
Since it says "-10" and hasn't found ten results yet, git log will
keep on searching back in history. I don't know of a way to say "give
up searching once you find the commit that creates this file",
although that would also do what I want. The end result is the same,
but it's very slow if the git log isn't in the OS/disk cache. On my
main development box, it is cached, but I just tried it on my Windows
box and it took about fifteen seconds to finish; and 760 commits is
not huge as repositories go - the Pike repo has over 30,000 commits,
and git's own repo is of similar size.
Bounding the search is potentially a huge improvement here, since the
user's waiting. But the exact limit depends on the repo itself, and
it'd be nice to be able to disable it ("huh, didn't find any
results... I'll de-limit the search and try again"). Hence the config
option, which I'm very happy to hear *is* a viable technique.
ChrisA
--
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