On Sun, May 12, 2013 at 03:19:49PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
But it is not a big problem. Either 3-way merge notices that there
is nothing new, or you get a conflict and have chance to inspect
what is going on.
It's not a problem here, but
John Keeping j...@keeping.me.uk writes:
The caching layer could also introduce false positives though, which is
more serious. If you cache patch IDs with a pathspec restriction ...
What? What business does patch-id have with pathspec-limited diff
generation? You do not rebase or cherry-pick
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
The caching layer could also introduce false positives though, which is
more serious. If you cache patch IDs with a pathspec restriction ...
What? What business does patch-id have
John Keeping j...@keeping.me.uk writes:
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
The caching layer could also introduce false positives though, which is
more serious. If you cache patch IDs with a pathspec restriction ...
On Mon, May 13, 2013 at 07:46:09AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
The caching layer could also introduce false positives though, which is
John Keeping j...@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
On Mon, May 13, 2013 at 08:45:21AM -0700, Junio C Hamano wrote:
John Keeping j...@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
On Sat, May 11, 2013 at 08:00:44PM -0700, Junio C Hamano wrote:
Linus Torvalds torva...@linux-foundation.org writes:
On Sat, May 11, 2013 at 2:49 PM, John Keeping j...@keeping.me.uk wrote:
Hmm... I hadn't realised that. Looking a bit closer, it looks like
init_patch_ids sets up its own
On Sat, May 11, 2013 at 06:57:02PM -0500, Johannes Schindelin wrote:
On Sat, 11 May 2013, Linus Torvalds wrote:
[...] I really think caching patch ID's should be something people
should be aware of is fundamentally wrong, even if it might work.
Given the incredible performance win, I
John Keeping j...@keeping.me.uk writes:
But it is not a big problem. Either 3-way merge notices that there
is nothing new, or you get a conflict and have chance to inspect
what is going on.
It's not a problem here, but false negatives would be annoying if you're
looking at git log
This adds a new configuration variable patchid.cacheRef which controls
whether (and where) patch IDs will be cached in a notes tree.
Caching patch IDs in this way results in a performance improvement in
every case I have tried, for example when comparing the git-gui tree to
git.git (where git-gui
On Sat, May 11, 2013 at 12:54 PM, John Keeping j...@keeping.me.uk wrote:
This adds a new configuration variable patchid.cacheRef which controls
whether (and where) patch IDs will be cached in a notes tree.
Patch ID's aren't stable wrt different diff options, so I think this
is potentially a
On Sat, May 11, 2013 at 02:10:01PM -0700, Linus Torvalds wrote:
On Sat, May 11, 2013 at 12:54 PM, John Keeping j...@keeping.me.uk wrote:
This adds a new configuration variable patchid.cacheRef which controls
whether (and where) patch IDs will be cached in a notes tree.
Patch ID's aren't
On Sat, May 11, 2013 at 2:49 PM, John Keeping j...@keeping.me.uk wrote:
Hmm... I hadn't realised that. Looking a bit closer, it looks like
init_patch_ids sets up its own diffopts so its not affected by the
command line (except for pathspecs which would be easy to check for).
Of course that
Hi John Linus,
On Sat, 11 May 2013, Linus Torvalds wrote:
[...] I really think caching patch ID's should be something people
should be aware of is fundamentally wrong, even if it might work.
Given the incredible performance win, I would say it is still worth
looking into.
If you store also
Linus Torvalds torva...@linux-foundation.org writes:
On Sat, May 11, 2013 at 2:49 PM, John Keeping j...@keeping.me.uk wrote:
Hmm... I hadn't realised that. Looking a bit closer, it looks like
init_patch_ids sets up its own diffopts so its not affected by the
command line (except for
16 matches
Mail list logo
