From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Wed, 25 Aug 2010 22:11:11 GMT
Subject: Re: [PATCH 11/32] rev-list: support --narrow-tree
Message-ID: <AANLkTimMGn9M9im2LdjYJkbg9QhUKq2a_4tRQEUoQM0c@mail.gmail.com>
In-Reply-To: <AANLkTi=KBThiZ_FBUh0RfzLtP=YAtUPcx5PJW1q5OCd4@mail.gmail.com>

On Wed, Aug 25, 2010 at 1:59 PM, Elijah Newren <newren@gmail.com> wrote:
> Hi,
>
> 2010/8/24 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>> These options allow plumbing to access narrow tree traverse modes.
>> As a consequence, tests can now be written to test these modes.
>>
> <snip>
>> +                       if (!prefixcmp(arg, "--narrow-tree=")) {
>> +                               revs->narrow_prefix = arg + 14;
>> +                               revs->narrow_tree = 1;
>> +                               continue;
>> +                       }
>
> Seems somewhat non-gittish.  Why not 'git rev-list --objects HEAD --
> <subtree_path>' rather than 'git rev-list --objects
> --narrow-tree=<subtree_path> HEAD'?  (Was it due to the current bug in
> rev-list when specifying both --objects and paths?  If so, that's
> addressed in the patch series I just sent.)

Yeah probably because of the --object bug that I did not know. Anyway
I still need "--narrow" signal because in my series, I would send all
trees that are not found in parents' trees for merge commits. A
requirement from remote merge.

>> +cat <<EOF >merge.expected
>> +0da28f8308e336bd4b2c26b61c7fc44e41a30e49
>> +7475cb8a389b36ce238b9ee6cbfdfa26a1b67e35
>> +af9c31c0e217154296d93d66b9a5a41892c7b321
>> +ba7a30916c792624a8372cb26da50f5594098222
>> +74a398027f0b59183db54ca8c67dc30b5aeed0ff t2
>
> Is this right?  Do you expect to see a t2 entry when filtering for t1/t12?

As I said above, if this "t2" is not seen in either parents, then it
must be sent/traversed, unfortunately.
-- 
Duy