Re: [PATCH v2] log: add --nonlinear-barrier to help see non-linear history

> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>>  v2 renames the option name to --nonlinear-barrier and fixes using it
>>  with --dense. Best used with --no-merges to see patch series.
>
> I think that the earlier name "show linear-break" is more easily
> understood than the new name, but maybe that is just me.  It's not
> like you are blocking something from going forward with a barrier,
> and internally it is called a "break-bar".

>>       opt->loginfo = NULL;
>>       maybe_flush_or_die(stdout, "stdout");
>>       return shown;
>
> Does this new feature interact with -z format output in any way?

>> +define_commit_slab(saved_linear, int);
>> +
>> +static void track_linear(struct rev_info *revs, struct commit *commit)
>> +{
>> +     struct commit_list *p = revs->previous_parents;
>> +
>> +     if (p) {
>> +             int got_parent = 0;
>> +             for (; p && !got_parent; p = p->next)
>> +                     got_parent = !hashcmp(p->item->object.sha1,
>> +                                           commit->object.sha1);
>> +             revs->linear = got_parent;
>> +             free_commit_list(revs->previous_parents);
>> +     } else
>> +             revs->linear = 1;
>> +     if (revs->reverse) {
>> +             if (!revs->saved_linear_slab) {
>> +                     revs->saved_linear_slab = xmalloc(sizeof(struct saved_linear));
>> +                     init_saved_linear(revs->saved_linear_slab);
>> +             }
>> +
>> +             *saved_linear_at(revs->saved_linear_slab, commit) = revs->linear;
>> +     }
>> +     revs->previous_parents = copy_commit_list(commit->parents);
>
> We are showing commit, and the parents (after history
> simplification) of the commit we showed before this commit is kept
> in previous-parents.  If we are one of them, we are showing
> linearly, which makes sense.  While we are accumulating the output
> in the forward direction in preparation for later emitting them in
> reverse, we need to save away the linear-ness bit somewhere, and a
> slab is a logical place to save that, which also makes sense.  But
> why do you need a full int?  Doesn't an unsigned char wide enough?