Re: [PATCH 00/17] Narrow clone v3 (was subtree clone)

From: Elijah Newren <newren@gmail.com>
Date: Sep 6, 2010, 05:17 UTC
Message-ID: <AANLkTinNnm=Z=e_=P_auuNgSrDynt_P+FLiZgWeNNgps@mail.gmail.com>
In-Reply-To: <1283669264-15759-1-git-send-email-pclouds@gmail.com>

Hi,

2010/9/5 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:

> I'll describe differences between this series and Elijah's one [1].
> I think it's more interesting. Changes from v2 [2] will follow later.

So, I downloaded your patches and even made sure to sort them appropriately to fix the order, but I'm getting conflicts trying to apply them (on top of current pu). What version did you base them on?

Show 9 quoted lines

> In short I think the two series are converging. The outstanding
> difference is Elijah drops shallow clone in favor of more flexible
> history cutting while I only focus on tree cutting.
>
> Two other differences are tree traversal and tree generating. I admit
> that changing traverse_trees() the way Elijah does is more flexible
> and is probably the only way to support negative pathspec. And I think
> his sparse clone supports even cloning a single file. Mine does not
> support that. I'm going to steal some of his patches at some point.

Yes, I can clone a single file.

> Tree generating from index, Elijah merges the base tree inside
> write_cache_as_tree() while it does it inside commit_tree(). Again the
> principle is pretty much the same. I'll see if I can resist from
> stealing some more :)

You're too modest; your comparison simply omitted some of the areas where your series shines, such as the get_pathspec fixes (my stuff was broken and much less complete), merge support, and nicer fetch/push/clone support. You also had some other nice touches (documentation updates, new rev-parse flag) that may not have been a big deal, but they're still nice. I'm going to be cherry-picking a lot of that stuff, and replacing the relevant bits of my series. Who knows, maybe we're converging quicker than it looked at first glance? :-)

> Things that won't work:
>
>  - Shell scripts that use "git write-tree"

Yeah, write-tree didn't work in mine either; I had to make it throw an error. But wouldn't your idea to make a tree object (referenced for sha1sums outside the sparse/narrow paths) part of the index allow even write-tree to work?

>  - only send commits that have changes in narrow area and graft it at
>   client side

After reviewing more of your changes, and replacing various patches of mine with yours, this is fairly high on my priority list as well (whereas fsck & prune are a bit lower). Maybe we can discuss ideas on tackling this when we start working on it. I've got some rough initial ideas (though I have no idea if they'll pan out); I'll see if I can write some of them up in the next day or two.

Elijah