Ye Xiaolong <xiaolong.ye@xxxxxxxxx> writes:
> On Thu, Mar 31, 2016 at 10:43:48AM -0700, Junio C Hamano wrote:
>>Xiaolong Ye <xiaolong.ye@xxxxxxxxx> writes:
>>
>>> Introduce --base=auto to record the base commit info automatically, the base_commit
>>> will be the merge base of tip commit of the upstream branch and revision-range
>>> specified in cmdline.
>>
>>This line is probably a bit too long.
>
> How about simplifying it to "the base_commit is the merge base of upstream and
> specified revision-range."?
What I meant was not that profound. I just wanted you to wrap your
lines a bit shorter so that quoting in the discussion thread like
this would not make the result overlong to fit on a 80-column
terminal ;-)
>>> + base = base_list->item;
>>> + free_commit_list(base_list);
>>
>>What should happen when there are multiple merge bases? The code
>>picks one at random and ignores the remainder, if I am reading this
>>correctly.
>
> If there is more than one merge base, commits in base_list should
> be sorted by date, if I am understanding it correctly, so
> base_list->item should be the lastest merge base commit, it should
> be enough for us to used as base commit.
By definition, when there are multiple merge bases, there is no
latest one among them.
When the history involves criss-cross merges, there can be more than
one 'best' common ancestor for two commits. For example, with this
topology (note that X is not a commit; it merely denotes crossing of
two lines):
---1---o---A
/ \ /
---O X
\ / \
---2---o---o---B
both '1' and '2' are merge-bases of 'A' and 'B'. And the timestamps
on one (be it committer or author timestamp) being later than those
of the other do not make it any more suitable than the other one.
--
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