Johannes Sixt writes:
> Am 12.10.18 um 08:33 schrieb Junio C Hamano:
>> "Derrick Stolee via GitGitGadget" writes:
>>> +struct topo_walk_info {};
>>> +
>>> +static void init_topo_walk(struct rev_info *revs)
>>> +{
>>> + struct topo_walk_info *info;
>>> + revs->topo_walk_info = xmalloc(sizeof(
Am 12.10.18 um 08:33 schrieb Junio C Hamano:
"Derrick Stolee via GitGitGadget" writes:
+struct topo_walk_info {};
+
+static void init_topo_walk(struct rev_info *revs)
+{
+ struct topo_walk_info *info;
+ revs->topo_walk_info = xmalloc(sizeof(struct topo_walk_info));
+ info = re
On 10/12/2018 2:33 AM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
* revs->limited implies we run limit_list() to walk the entire
reachable set. There are some short-cuts here, such as if we
perform a range query like 'git rev-list COMPARE..HEAD' and we
can stop li
"Derrick Stolee via GitGitGadget" writes:
> * revs->limited implies we run limit_list() to walk the entire
> reachable set. There are some short-cuts here, such as if we
> perform a range query like 'git rev-list COMPARE..HEAD' and we
> can stop limit_list() when all queued commits are unin
On Fri, Sep 21, 2018 at 10:39:32AM -0700, Derrick Stolee via GitGitGadget wrote:
> [..]
> When setting revs->limited only because revs->topo_order is true,
> only do so if generation numbers are not available. There is no
> reason to use the new logic as it will behave similarly when all
> generat
From: Derrick Stolee
When running 'git rev-list --topo-order' and its kin, the topo_order
setting in struct rev_info implies the limited setting. This means
that the following things happen during prepare_revision_walk():
* revs->limited implies we run limit_list() to walk the entire
reachable
6 matches
Mail list logo
