On Mon, May 13, 2013 at 08:45:21AM -0700, Junio C Hamano wrote:
> John Keeping 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 mo
John Keeping 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...fea
On Mon, May 13, 2013 at 07:46:09AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
> >> John Keeping writes:
> >>
> >> > The caching layer could also introduce false positives though, which is
> >> > more serious. If you
John Keeping writes:
> On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
>> John Keeping 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 d
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
> John Keeping 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
John Keeping 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 with pathspec, s
On Sun, May 12, 2013 at 03:19:49PM -0700, Junio C Hamano wrote:
> John Keeping 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
John Keeping 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 --cherry-mark".
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
On Sat, May 11, 2013 at 08:00:44PM -0700, Junio C Hamano wrote:
> Linus Torvalds writes:
>
> > On Sat, May 11, 2013 at 2:49 PM, John Keeping 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 th
Linus Torvalds writes:
> On Sat, May 11, 2013 at 2:49 PM, John Keeping 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).
>
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 als
On Sat, May 11, 2013 at 2:49 PM, John Keeping 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 still means it
On Sat, May 11, 2013 at 02:10:01PM -0700, Linus Torvalds wrote:
> On Sat, May 11, 2013 at 12:54 PM, John Keeping 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 d
On Sat, May 11, 2013 at 12:54 PM, John Keeping 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 very bad idea.
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-gu
16 matches
Mail list logo
