Re: [PATCH v3 10/9] revision.c: treat A...B merge bases as if manually specified

From: Junio C Hamano <gitster@pobox.com>
Date: May 6, 2013, 21:24 UTC
Message-ID: <7vli7rpzt0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1367859096-25909-1-git-send-email-kevin@bracey.fi>

Kevin Bracey <kevin@bracey.fi> writes:

> The documentation assures users that "A...B" is defined as 'r1 r2 --not
> $(git merge-base --all r1 r2)'. This isn't in fact quite true, because
> the calculated merge bases are not sent to add_rev_cmdline().

We want the commands to be able to tell which ones in revs->pending and revs->commits were specified by the end user and how. While I think it makes sense to mark these negative merge bases with "These came from the command line with A...B syntax", I am not sure if it is the best way to do so in add_pending_commit_list().

By the way, why does this have anything to do with the history traversal series in the first place?

When there is anythning marked UNINTERESTING on the rev->pending before calling prepare_revision_walk(), you have a history with some bottom boundaries, and when there isn't, your bottom boundaries are root commits. If you want to behave differently depending on how the user gave us the revision range from the command line, e.g. acting differently between "A ^B" and "B..A", cmdline is a good place to learn the exact form, but at the history traversal level, I do not think you should even care. Why does the code even look at the cmdline, and not rev->pending?