John Keeping [off-list ref] writes:
On Tue, Jun 30, 2015 at 02:10:49PM +0200, Johannes Schindelin wrote:
quoted
On 2015-06-29 18:46, Lawrence Siebert wrote:
quoted
I appreciate your help. Okay, That all makes sense.
I would note that something like:
git shortlog -s "$FILENAME: | cut -f 1 | paste -sd+ - | bc
seems like it run much faster then:
git log --oneline "$FILENAME" | wc -l
How does it compare to `git rev-list -- "$FILENAME" | wc -l`?
Or even `git rev-list --count HEAD -- "$FILENAME"`.
Ahh, OK. I didn't know we already had "rev-list --count".
Then please disregard the suggestion to add the option to "log"; it
still holds true that the option does not belong to "shortlog", but
I do think "how many changes were made to this path" statistics
driven by a script should use "rev-list" plumbing, and if it already
has "--count" option, that is perfect ;-)
Thanks.
On Fri, Jul 3, 2015 at 10:31 AM, Junio C Hamano [off-list ref] wrote:
John Keeping [off-list ref] writes:
quoted
On Tue, Jun 30, 2015 at 02:10:49PM +0200, Johannes Schindelin wrote:
quoted
On 2015-06-29 18:46, Lawrence Siebert wrote:
quoted
I appreciate your help. Okay, That all makes sense.
I would note that something like:
git shortlog -s "$FILENAME: | cut -f 1 | paste -sd+ - | bc
seems like it run much faster then:
git log --oneline "$FILENAME" | wc -l
How does it compare to `git rev-list -- "$FILENAME" | wc -l`?
Or even `git rev-list --count HEAD -- "$FILENAME"`.
Ahh, OK. I didn't know we already had "rev-list --count".
Then please disregard the suggestion to add the option to "log"; it
still holds true that the option does not belong to "shortlog", but
I do think "how many changes were made to this path" statistics
driven by a script should use "rev-list" plumbing, and if it already
has "--count" option, that is perfect ;-)
Thanks.
Junio,
I think, respectfully, there is still a benefit to adding it as a
feature to "log", in that more Git users know of and use "log" than
"rev-list". I hadn't heard of "rev-list" before joining this mailing
list.
That means "log --count" will get used more. That also means that more
eyeballs will hit --count with bug reports and better tests; I've
already seen 2-3 suggestions for "log --count" tests that "rev-list
--count" also doesn't have tests for.
I would like to keep working on implementing "log --count", sharing
code with rev-list where possible so they both are improved, unless
you are saying you won't merge.
Thanks,
Lawrence
--
About Me: http://about.me/lawrencesiebert
Constantly Coding: http://constantcoding.blogspot.com
Lawrence Siebert wrote:
On Fri, Jul 3, 2015 at 10:31 AM, Junio C Hamano [off-list ref] wrote:
quoted
John Keeping [off-list ref] writes:
quoted
quoted
Or even `git rev-list --count HEAD -- "$FILENAME"`.
Ahh, OK. I didn't know we already had "rev-list --count".
Then please disregard the suggestion to add the option to "log"; it
still holds true that the option does not belong to "shortlog", but
I do think "how many changes were made to this path" statistics
driven by a script should use "rev-list" plumbing, and if it already
has "--count" option, that is perfect ;-)
Junio,
I think, respectfully, there is still a benefit to adding it as a
feature to "log", in that more Git users know of and use "log" than
"rev-list". I hadn't heard of "rev-list" before joining this mailing
list.
That means "log --count" will get used more. That also means that more
eyeballs will hit --count with bug reports and better tests; I've
already seen 2-3 suggestions for "log --count" tests that "rev-list
--count" also doesn't have tests for.
I would like to keep working on implementing "log --count", sharing
code with rev-list where possible so they both are improved, unless
you are saying you won't merge.
Lawrence,
As git-rev-list is (mainly) plumbing for git-log porcelain, I think
what you would need to do to add "--count" support to "git log" is
just parse option, exclude nonsense combinations, and pass down to
the revision parsing machinery.
HTH
--
Jakub Narębski