"Philip Oakley" writes:
> The study of human error is quite interesting
Yes ;-)
Christian Couder writes:
> I think I just copy pasted the code from cmd_rev_list() in
> builtin-rev-list.c and probably didn't realize that revs->tree_objects
> would always be false.
>
> Thanks for spotting this and removing the dead code.
Thanks for a quick confirmation. Just FYI I was looking
From: "Junio C Hamano"
"Philip Oakley" writes:
Bikeshedding: If the given boundary is a tag, it could be tagging a
blob or tree rather than a commit. Would that be a scenario that
reaches this part of the code?
I do not think it is relevant.
Bisection is an operation over a "bisectable" co
"Philip Oakley" writes:
> Bikeshedding: If the given boundary is a tag, it could be tagging a
> blob or tree rather than a commit. Would that be a scenario that
> reaches this part of the code?
I do not think it is relevant.
Bisection is an operation over a "bisectable" commit DAG, where
commit
From: "Junio C Hamano"
Ever since "bisect--helper" was introduced in 1bf072e366
("bisect--helper: implement "git bisect--helper"", 2009-03-26),
after setting up the "rev-list $bad --not $good_ones" machinery, the
code somehow prepared to mark the trees and blobs at the good boundary
as uninteres
On Fri, Mar 3, 2017 at 5:16 PM, Junio C Hamano wrote:
> Ever since "bisect--helper" was introduced in 1bf072e366
> ("bisect--helper: implement "git bisect--helper"", 2009-03-26),
> after setting up the "rev-list $bad --not $good_ones" machinery, the
> code somehow prepared to mark the trees and bl
Ever since "bisect--helper" was introduced in 1bf072e366
("bisect--helper: implement "git bisect--helper"", 2009-03-26),
after setting up the "rev-list $bad --not $good_ones" machinery, the
code somehow prepared to mark the trees and blobs at the good boundary
as uninteresting, only when --objects
7 matches
Mail list logo
