On Wed, Feb 05, 2014 at 02:58:36PM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@navytux.spb.ru writes:
On Wed, Feb 05, 2014 at 11:42:41AM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@navytux.spb.ru writes:
I agree object data should be immutable for good. The only thing I'm
On Tue, Feb 04, 2014 at 10:37:24AM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@mns.spb.ru 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 k...@mns.spb.ru 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
On Wed, Feb 05, 2014 at 09:36:55AM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@mns.spb.ru 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
---
Kirill Smelkov k...@navytux.spb.ru 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
On Wed, Feb 05, 2014 at 11:42:41AM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@navytux.spb.ru 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
Kirill Smelkov k...@navytux.spb.ru writes:
On Wed, Feb 05, 2014 at 11:42:41AM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@navytux.spb.ru 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
On Mon, Feb 03, 2014 at 03:39:02PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Kirill Smelkov k...@mns.spb.ru writes:
As was recently shown (c839f1bd combine-diff: optimize
combine_diff_path sets intersection), combine-diff runs very slowly. In
that commit we
Kirill Smelkov k...@mns.spb.ru 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
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 lot
Kirill Smelkov k...@mns.spb.ru 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,
Junio C Hamano gits...@pobox.com writes:
Kirill Smelkov k...@mns.spb.ru 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%
Kirill Smelkov k...@mns.spb.ru 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
13 matches
Mail list logo
