From: John Keeping <john@keeping.me.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Git Mailing List <git@vger.kernel.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] patch-ids.c: cache patch IDs in a notes tree
Date: Mon, 13 May 2013 16:52:41 +0100 [thread overview]
Message-ID: <20130513155241.GS2299@serenity.lan> (raw)
In-Reply-To: <7vd2suopda.fsf@alter.siamese.dyndns.org>
On Mon, May 13, 2013 at 08:45:21AM -0700, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> 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)?
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.
prev parent reply other threads:[~2013-05-13 15:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-11 19:54 [PATCH] patch-ids.c: cache patch IDs in a notes tree John Keeping
2013-05-11 21:10 ` Linus Torvalds
2013-05-11 21:49 ` John Keeping
2013-05-11 22:41 ` Linus Torvalds
2013-05-11 23:57 ` Johannes Schindelin
2013-05-12 9:08 ` John Keeping
2013-05-12 11:41 ` [RFC/PATCH v2] patch-ids: " John Keeping
2013-05-12 11:57 ` John Keeping
2013-05-12 3:00 ` [PATCH] patch-ids.c: " Junio C Hamano
2013-05-12 8:59 ` John Keeping
2013-05-12 22:19 ` Junio C Hamano
2013-05-13 7:59 ` John Keeping
2013-05-13 13:53 ` Junio C Hamano
2013-05-13 14:02 ` John Keeping
2013-05-13 14:46 ` Junio C Hamano
2013-05-13 14:59 ` John Keeping
2013-05-13 15:45 ` Junio C Hamano
2013-05-13 15:52 ` John Keeping [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130513155241.GS2299@serenity.lan \
--to=john@keeping.me.uk \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.