On Wed, Feb 05, 2014 at 02:58:36PM -0800, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > On Wed, Feb 05, 2014 at 11:42:41AM -0800, Junio C Hamano wrote:
> >> Kirill Smelkov writes:
> >>
> >> > I agree object data should be immutable for good. The only thing I'm
> >> > talking
> >> > abou
Kirill Smelkov writes:
> On Wed, Feb 05, 2014 at 11:42:41AM -0800, Junio C Hamano wrote:
>> Kirill Smelkov writes:
>>
>> > I agree object data should be immutable for good. The only thing I'm
>> > talking
>> > about here is mode, which is parsed from a tree buffer and is stored in
>> > separat
On Wed, Feb 05, 2014 at 11:42:41AM -0800, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > I agree object data should be immutable for good. The only thing I'm talking
> > about here is mode, which is parsed from a tree buffer and is stored in
> > separate field:
>
> Ah, I do not see any pro
Kirill Smelkov writes:
> I agree object data should be immutable for good. The only thing I'm talking
> about here is mode, which is parsed from a tree buffer and is stored in
> separate field:
Ah, I do not see any problem in that case, then.
Thanks.
--
To unsubscribe from this list: send the l
On Wed, Feb 05, 2014 at 09:36:55AM -0800, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > Only, before I clean things up, I'd like to ask - would the following
> > patch be accepted
> >
> > 8< ---
> > diff --git a/tree-walk.c b/tree-walk.c
> > index 79dba1d..4dc86c7 100644
> > --- a/tre
Kirill Smelkov writes:
> Only, before I clean things up, I'd like to ask - would the following
> patch be accepted
>
> 8< ---
> diff --git a/tree-walk.c b/tree-walk.c
> index 79dba1d..4dc86c7 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> @@ -37,7 +37,7 @@ static void decode_tree_entry(str
On Tue, Feb 04, 2014 at 10:37:24AM -0800, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> >> if we did not want to reinvent the whole tree walking thing, which
> >> would add risks for new bugs and burden to maintain this and the
> >> usual two-tree diff tree walking in sync.
> >
> > Junio, I
Kirill Smelkov writes:
>> if we did not want to reinvent the whole tree walking thing, which
>> would add risks for new bugs and burden to maintain this and the
>> usual two-tree diff tree walking in sync.
>
> Junio, I understand it is not good to duplicate code and increase
> maintenance risks..
On Mon, Feb 03, 2014 at 03:39:02PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Kirill Smelkov writes:
> >
> >> As was recently shown (c839f1bd "combine-diff: optimize
> >> combine_diff_path sets intersection"), combine-diff runs very slowly. In
> >> that commit we optimized paths
Kirill Smelkov writes:
> + parents_sha1 = xmalloc(nparent * sizeof(parents_sha1[0]));
> + for (i = 0; i < nparent; i++)
> + parents_sha1[i] = parents->sha1[i];
> +
> + /* fake list head, so worker can assume it is non-NULL */
> + struct combine_diff_path paths_head;
d
Junio C Hamano writes:
> Kirill Smelkov writes:
>
>> As was recently shown (c839f1bd "combine-diff: optimize
>> combine_diff_path sets intersection"), combine-diff runs very slowly. In
>> that commit we optimized paths sets intersection, but that accounted
>> only for ~ 25% of the slowness, and
Kirill Smelkov writes:
> As was recently shown (c839f1bd "combine-diff: optimize
> combine_diff_path sets intersection"), combine-diff runs very slowly. In
> that commit we optimized paths sets intersection, but that accounted
> only for ~ 25% of the slowness, and as my tracing showed, for linux.
As was recently shown (c839f1bd "combine-diff: optimize
combine_diff_path sets intersection"), combine-diff runs very slowly. In
that commit we optimized paths sets intersection, but that accounted
only for ~ 25% of the slowness, and as my tracing showed, for linux.git
v3.10..v3.11, for merges a lo
13 matches
Mail list logo
