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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).