On 10/13/2017 10:26 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote:
This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is
causing diff_can_quit_early() to return false. Due to the corner-case of the
bug it seems it will not be a huge perfor
On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote:
> This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is
> causing diff_can_quit_early() to return false. Due to the corner-case of the
> bug it seems it will not be a huge performance improvement in most cases.
> Sti
On 10/13/2017 10:20 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 10:10:18AM -0400, Jeff King wrote:
Hmm. So this patch makes it go fast:
diff --git a/revision.c b/revision.c
index d167223e69..b52ea4e9d8 100644
--- a/revision.c
+++ b/revision.c
@@ -409,7 +409,7 @@ static void file_add_remove(st
On Fri, Oct 13, 2017 at 10:10:18AM -0400, Jeff King wrote:
> Hmm. So this patch makes it go fast:
>
> diff --git a/revision.c b/revision.c
> index d167223e69..b52ea4e9d8 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -409,7 +409,7 @@ static void file_add_remove(struct diff_options *options,
>
On Fri, Oct 13, 2017 at 09:56:36AM -0400, Jeff King wrote:
> On Fri, Oct 13, 2017 at 09:55:15AM -0400, Derrick Stolee wrote:
>
> > > We should be comparing an empty tree and d0/d0/d0/d0 (or however deep
> > > your pathspec goes). We should be able to see immediately that the entry
> > > is not pr
On Fri, Oct 13, 2017 at 09:55:15AM -0400, Derrick Stolee wrote:
> > We should be comparing an empty tree and d0/d0/d0/d0 (or however deep
> > your pathspec goes). We should be able to see immediately that the entry
> > is not present between the two and not bother descending. After all,
> > we've
On 10/13/2017 9:50 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 09:39:14AM -0400, Derrick Stolee wrote:
Since I don't understand enough about the consumers to diff_tree_oid() (and
the fact that the recursive behavior may be wanted in some cases), I think
we can fix this in builtin/rev-list.c wi
On Fri, Oct 13, 2017 at 09:39:14AM -0400, Derrick Stolee wrote:
> Since I don't understand enough about the consumers to diff_tree_oid() (and
> the fact that the recursive behavior may be wanted in some cases), I think
> we can fix this in builtin/rev-list.c with this simple diff:
>
> ---
>
> di
On 10/13/2017 9:15 AM, Derrick Stolee wrote:
On 10/13/2017 8:44 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote:
On 13.10.2017 15:04, Junio C Hamano wrote:
Christian Couder writes:
Yeah, but perhaps Git could be smarter when rev-listing too and avoid
proces
On 10/13/2017 8:44 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote:
On 13.10.2017 15:04, Junio C Hamano wrote:
Christian Couder writes:
Yeah, but perhaps Git could be smarter when rev-listing too and avoid
processing files or directories it has already seen?
On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote:
> On 13.10.2017 15:04, Junio C Hamano wrote:
> > Christian Couder writes:
> >
> > > Yeah, but perhaps Git could be smarter when rev-listing too and avoid
> > > processing files or directories it has already seen?
> >
> > Aren't you su
On Fri, Oct 13, 2017 at 07:06:03PM +0900, Mike Hommey wrote:
> On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
> > There's a gitbomb on github. It is undoubtedly creative and funny, but since
> > this is a bug in git, I thought it'd be nice to report. The command:
> >
> > $ git c
On 13.10.2017 15:04, Junio C Hamano wrote:
Christian Couder writes:
Yeah, but perhaps Git could be smarter when rev-listing too and avoid
processing files or directories it has already seen?
Aren't you suggesting to optimize for a wrong case?
Anything that is possible with a software shou
Christian Couder writes:
> Yeah, but perhaps Git could be smarter when rev-listing too and avoid
> processing files or directories it has already seen?
Aren't you suggesting to optimize for a wrong case?
On Fri, Oct 13, 2017 at 12:37 PM, Mike Hommey wrote:
> On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote:
>>
>> After cloning it with -n, there is the following "funny" situation:
>>
>> $ time git rev-list HEAD
>> 7af99c9e7d4768fa681f4fe4ff61259794cf719b
>> 18ed56cbc5012117e24a603e7
On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote:
> On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey wrote:
> > On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
> >> There's a gitbomb on github. It is undoubtedly creative and funny, but
> >> since
> >> this is a bug in gi
On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey wrote:
> On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
>> There's a gitbomb on github. It is undoubtedly creative and funny, but since
>> this is a bug in git, I thought it'd be nice to report. The command:
>>
>> $ git clone https:
On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
> There's a gitbomb on github. It is undoubtedly creative and funny, but since
> this is a bug in git, I thought it'd be nice to report. The command:
>
> $ git clone https://github.com/x0rz/ShadowBrokersFiles
What fills memory is
18 matches
Mail list logo