On 2021-02-24 at 17:58:34, Michal Suchánek wrote:
> Hello,
> 
> I find the results of git merge-base A B quite useless.
> 
> Suppose you have a repository with file sets
> 
> S and T
> 
> where S are sources which are developed in mainline and number of stable
> versions, and feature branches, and T are build tools (such as autoconf
> tests or whatever) that are largely independent of the source version.
> 
> Because of the independence of T from S T are developed in a separate
> branch t which is merged into all branches developing S as needed.
> 
> Fixes to S may affect more than one version, and depending on the
> situation it might be useful to apply fixes to S to mutiple
> stable/feature branche at once. For that one would need a merge base of
> the branches in question.
> 
> However, merge-base almost always give a commit on branch t which is the
> merge base of files in set T and does not contain files in set S at all.
> In other words it is merge base only for files from set T and not set S.
> Can I get merge base that is merge base for all files that have common
> history between two branches?

The merge base is determined by the history.  In your case, I imagine
you have a history like this:

 A -- B -- C -- D -- E -- F -- G (S)
        _/        _/        _/
 H -- I -- J -- K -- L -- M -- N (T)

Here, the merge base of N and G is M, and the merge base of F and M is
K.  Those are the most recent common ancestors, which are typically
chosen as the merge base.

In your case, you probably want to cherry-pick a commit, or maybe rebase
a small set of commits onto another set.  That would probably work
better than trying to merge.  It's possible that there's something about
this case that I'm missing where it wouldn't work properly, but it's
definitely the approach I would try.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US