Re: check if one branch contains another branch

[Alexander Mills <alexander.d.mills@gmail.com>]

I assume that:

git branch -d  xxx

will prevent a delete if the current branch doesn't contain xxx..
I don't want to have to checkout  origin/dev in order to run that command,
that's one part of the problem


On Thu, May 7, 2020 at 4:31 PM Randall S. Becker <rsbecker@nexbridge.com> wrote:
>
> On May 7, 2020 6:59 PM Alexander Mills, Wrote:
> > To: git@vger.kernel.org
> > Subject: check if one branch contains another branch
> >
> > I am looking for a command:
> >
> > 1>  if branch x contains branch y
> >
> > right now all I can find is
> >
> > 2> if current branch contains commit y
> >
> > can someone please accomplish #1 ?
> > Crazy hard to find an answer to #1 online.
> > The user case is to delete old local branches by comparing them with the
> > remote integration branch.
> >
> > more info if needed:
> > https://stackoverflow.com/questions/61669056/how-to-determine-if-
> > integration-branch-contains-feature-branch
>
> Looking at this slightly differently, if you try to delete a branch, git branch -d feature-branch, and the branch has not been merged, then the delete will fail. A simple way of looking at it is if the HEAD of the branch has no successor commits then it is not merged (not 100% decisive, but git branch -d is). It is not really that a branch has been merged, but that a commit has successors, meaning that it has been merged. However, unless you are using GitLab, a git merge --squash will not answer your question even if the branch was merged.
>
> A better way of looking at this is in terms of Pull (GitHub, BitBucket) or Merge (GitLab) requests. Has there been a Pull Request for a branch and has the branch been closed? Meaning that when you do a git fetch --prune, your merged/deleted branches go away unless you are on that branch. Looking at the Pull Request history is much more useful in determining whether a branch has been integrated into a main development branch or production branch in a GitFlow process.
>
> It is a different way of looking at the problem, but IMHO, a more representative way when taking developers and deployment into account.
>
> Regards,
> Randall
>


-- 
Alexander D. Mills
New cell phone # (415)730-1805
linkedin.com/in/alexanderdmills