Commit 941ba8db57 (Eliminate recursion in setting/clearing
marks in commit list, 2012-01-14) used a clever double-loop
to avoid allocations for single-parent chains of history.
However, it did so only when following parents of parents
(which was an uncommon case), and _always_ incurred at least
one
On 5/11/2018 2:03 PM, Jeff King wrote:
Commit 941ba8db57 (Eliminate recursion in setting/clearing
marks in commit list, 2012-01-14) used a clever double-loop
to avoid allocations for single-parent chains of history.
However, it did so only when following parents of parents
(which was an uncommon
On Mon, May 14, 2018 at 08:47:33AM -0400, Derrick Stolee wrote:
> On 5/11/2018 2:03 PM, Jeff King wrote:
> > Commit 941ba8db57 (Eliminate recursion in setting/clearing
> > marks in commit list, 2012-01-14) used a clever double-loop
> > to avoid allocations for single-parent chains of history.
> >
On 5/14/2018 9:09 AM, Jeff King wrote:
On Mon, May 14, 2018 at 08:47:33AM -0400, Derrick Stolee wrote:
On 5/11/2018 2:03 PM, Jeff King wrote:
Commit 941ba8db57 (Eliminate recursion in setting/clearing
marks in commit list, 2012-01-14) used a clever double-loop
to avoid allocations for single-p
On Mon, May 14, 2018 at 09:25:46AM -0400, Derrick Stolee wrote:
> > I think you'd want to go the other way: this is marking uninteresting
> > commits, so you'd want origin/master..master, which would make those 70k
> > commits uninteresting.
>
> Thanks for the tip. Running 'git rev-list origin/ma
5 matches
Mail list logo