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?
