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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Bracey <kevin@xxxxxxxxx> 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?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]