On Thu, Feb 25, 2021 at 12:04 PM Junio C Hamano <gitster@xxxxxxxxx> 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----o----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? > > 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? No, I think you're totally right; I was looking at (t) and (a) rather than (a) and (b) for some reason. As you point out, (s) isn't a merge-base of (a) and (b), so it wouldn't be printed by `git merge-base --all` either.
