Getting an actuallt useful merge base?

> 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?

> 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.

>
> On Thu, Feb 25, 2021 at 02:40:59AM +0000, brian m. carlson wrote:
> > 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.
>
> 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.

>> 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?

>
> Elijah Newren <newren@gmail.com> 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?

> Elijah Newren <newren@gmail.com> 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?