Hi Junio,
On Thu, Sep 17, 2020 at 10:16:51AM -0700, Junio C Hamano wrote:
> Denton Liu <liu.denton@xxxxxxxxx> writes:
>
> > +void diff_get_merge_base(const struct rev_info *revs, struct object_id *mb)
> > +{
> > + int i;
> > + struct commit *mb_child[2] = {0};
> > + struct commit_list *merge_bases;
> > +
> > + for (i = 0; i < revs->pending.nr; i++) {
> > + struct object *obj = revs->pending.objects[i].item;
> > + if (obj->flags)
> > + die(_("--merge-base does not work with ranges"));
> > + if (obj->type != OBJ_COMMIT)
> > + die(_("--merge-base only works with commits"));
> > + }
>
> This is the first use of die() in this file, that is designed to
> keep a set of reusable library functions so that the caller(s) can
> do their own die(). They may want to become
Although this is the first instance of die(), run_diff_index() has an
exit(128), which is basically a die() in disguise.
> return error(_(...));
>
> The same comment applies to all die()s the patch adds.
I applied this change but then each callsite of diff_get_merge_base()
became something like
if (diff_get_merge_base(revs, &oid))
exit(128);
so I do agree with the spirit of the change but in reality, it just
creates more busywork for the callers.
> > + /*
> > + * This check must go after the for loop above because A...B
> > + * ranges produce three pending commits, resulting in a
> > + * misleading error message.
> > + */
>
> Should "git diff --merge-base A...B" be forbidden, or does it just
> ask the same thing twice and is not a die-worthy offence?
I think that it should be die-worthy because it's a logic error for a
user to do this. I can't think of any situation where it wouldn't be
more desirable error early to correct a user's thinking. Plus, we're
trying to move away from the `...` notation anyway ;)
> > + for (i = 0; i < revs->pending.nr; i++)
> > + mb_child[i] = lookup_commit_reference(the_repository, &revs->pending.objects[i].item->oid);
> > + if (revs->pending.nr < ARRAY_SIZE(mb_child)) {
> > + struct object_id oid;
> > +
> > + if (revs->pending.nr != 1)
> > + BUG("unexpected revs->pending.nr: %d", revs->pending.nr);
>
> This is an obviously impossible condition as we will not take more
> than 2.
We also want to ensure that revs->pending.nr isn't 0 here. That being
said, I can explicitly check earlier in the function that the number of
pending is 1 or 2 so that it's more clearly written.
Thanks,
Denton
