git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: Getting an actuallt useful merge base?
Date: Thu, 25 Feb 2021 19:29:25 +0100	[thread overview]
Message-ID: <20210225182924.GY6564@kitsune.suse.cz> (raw)
In-Reply-To: <YDcOOwBOR4rO3sGr@camp.crustytoothpaste.net>

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.

Thanks

Michal

  reply	other threads:[~2021-02-25 18:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24 17:58 Getting an actuallt useful merge base? Michal Suchánek
2021-02-25  2:40 ` brian m. carlson
2021-02-25 18:29   ` Michal Suchánek [this message]
2021-02-25 19:52     ` Elijah Newren
2021-02-25 20:03       ` Junio C Hamano
2021-02-25 20:16         ` Elijah Newren
2021-02-25 20:26         ` Michal Suchánek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210225182924.GY6564@kitsune.suse.cz \
    --to=msuchanek@suse.de \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).