On Tue, Mar 18, 2014 at 3:32 AM, Junio C Hamano <[email protected]> wrote:
> Nguyễn Thái Ngọc Duy <[email protected]> writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
>> ---
>> 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".
I'll change it back.
>> opt->loginfo = NULL;
>> maybe_flush_or_die(stdout, "stdout");
>> return shown;
>
> Does this new feature interact with -z format output in any way?
Hmm.. never thought of it. Right now it's part of the previous commit.
> Should it, and if so how?
No idea.
>> +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?
Yes it is. Will change.
> I also wondered if the saved-parents slab we already have can be
> easily reused for this, but it probably would not help.
That could end up a maintenance nightmare. revision.c is complex
enough as it is.
> I do not quite understand the "if we do not have previous parents"
> bit, though. Is it meant to trigger only at the very beginning?
Only at the beginning.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
