John Keeping [off-list ref] writes:
This has the advantage that you get the benefit of the cache if you run
"git log --cherry-mark" with the same paths more than once. In my
testing the cache is beneficial as soon as you examine more than one
similar range (e.g. master...feature-A and then master...feature-B).
OK, so perhaps the notes that are keyed with commit ID will record
multiple entries, one for each invocation pattern (i.e. all pathspec
given, possibly with nonstandard options)?
"git diff -- t Documentation" and "git diff -- Docu\* t", even
though they use different pathspec, would produce the same diff;
instead of pathspec you may need to key with the actual list of
paths in the patch, though.
On Mon, May 13, 2013 at 08:45:21AM -0700, Junio C Hamano wrote:
John Keeping [off-list ref] writes:
quoted
This has the advantage that you get the benefit of the cache if you run
"git log --cherry-mark" with the same paths more than once. In my
testing the cache is beneficial as soon as you examine more than one
similar range (e.g. master...feature-A and then master...feature-B).
OK, so perhaps the notes that are keyed with commit ID will record
multiple entries, one for each invocation pattern (i.e. all pathspec
given, possibly with nonstandard options)?
That would be possible, but I didn't do it in the current version of the
patch.
"git diff -- t Documentation" and "git diff -- Docu\* t", even
though they use different pathspec, would produce the same diff;
instead of pathspec you may need to key with the actual list of
paths in the patch, though.
Maybe, but I think that would be overkill.
I'm interested to see how much of a benefit we could get by not
calculating the patch ID of any commits on the larger side of a
symmetric range that touch paths outside the set touched by the smaller
side. (revision.c::cherry_pick_list() remembers patch IDs for the
smaller side of a symmetric range and then checks if anything on the
larger side matches so this fits in naturally.)
In my usage I generally compare a relatively small topic branch against
whatever has happened in some upstream branch so I think this could give
a big improvement but I haven't had time to try it yet.