On Thu, Feb 25, 2021 at 12:03:58PM -0800, Junio C Hamano wrote: > Elijah Newren <newren@xxxxxxxxx> writes: > > >> It's like this > >> > >> T > >> ----o----o----o----o----o----o----o----o----o----o----o----o---(t)---o----o---- > >> \ \ \ \\\ > >> \ \ \ \\\ > >> \ \ \ \\\ > >> \ o----o----o\̶---o---(s)---o----o----o----o----o----o\̶\̶-(a) > >> \ / \ / \\ > >> S+T o----o----o----o----o----o---(u)---o----o----o----o----o----o----o\̶--(b) > >> / / \ > >> ---o----o----o----o----o----o----o----o----o----o----o----o----o----o----o---(m) > >> > >> So (t) is common ancestor for (a) and (b) that merge-base reports but it is > >> only ancestor for files in set T, and does not have files from set S at all. > >> The common ancestor I am insterested in is (s) which is merge base for both > >> sets of files. > > > > From git-merge-base(1): > > > > "When the history involves criss-cross merges, there can be more than > > one best common ancestor for two commits...When the --all option is > > not given, it is unspecified which best one is output." > > > > Perhaps you want to specify --all to git merge-base, and then perform > > additional checks on the output to select one yourself? The description does not inspire much confidence but it indeed gives something reasonable (ie what looks like would be (t) (u) in this situation). Nonetheless, (t) is clearly inferior and is reported by default when --all is not given. > > Ignore me, as it is likely I am just confused, but if we are merging > (a) and (b), I do not think (s) could be usable as a merge base; it > may be an ancestor of (a) but is not an ancestor of (b), no? Indeed, it should be the parent of (s) on the (b) branch - (u). Thanks Michal
