Duy Nguyen writes:
> Hmm.. no? the commit-slab stores the pointer to the weight, not the
> weight itself, so we still have the ability to check the third case, I
> think.
Good, thanks.
On Tue, Aug 28, 2018 at 6:45 PM Junio C Hamano wrote:
> > @@ -146,10 +147,14 @@ static void show_list(const char *debug, int counted,
> > int nr,
>
> An unrelated tangent, but I think I just spotted a bug in the
> existing code on the line immediately before this hunk, which reads
>
>
Junio C Hamano writes:
> Something like the following, perhaps?
Having said all that.
> +# See the drawing near the top --- e4 is in the middle of the first parent
> chain
> +printf "%s\n" e4 |
> +test_output_expect_success '--bisect --first-parent' '
> + git rev-list --bisect
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> I would have preferred to reuse the already existing commits generated in
>> the `setup` phase rather than generating yet another batch, and to not
>> introduce an inconsistent way to present a commit graph (compare your
>> diagram with
Johannes Schindelin writes:
> Hi Tiago,
>
> On Tue, 28 Aug 2018, Tiago Botelho wrote:
>
>> This will enable users to implement bisecting on first parents
>> which can be useful for when the commits from a feature branch
>> that we want to merge are not always tested.
>
> This message is still
Tiago Botelho writes:
> diff --git a/bisect.c b/bisect.c
> index 4eafc8262..cb80f29c5 100644
> --- a/bisect.c
> +++ b/bisect.c
> @@ -82,15 +82,16 @@ static inline void weight_set(struct commit_list *elem,
> int weight)
> *((int*)(elem->item->util)) = weight;
> }
>
> -static int
Hi Tiago,
On Tue, 28 Aug 2018, Tiago Botelho wrote:
> This will enable users to implement bisecting on first parents
> which can be useful for when the commits from a feature branch
> that we want to merge are not always tested.
This message is still lacking the explanation I asked for, namely
7 matches
Mail list logo
