Removing fully-merged branches

Removing fully-merged branches

[Vojtěch Vladyka]

Hello!

Permanent issue popping up in our team is removing local branches which were fully merged. 

I know there are command chains doing this job usually starting with git branch --merged followed by grep and ending with git branch -d but my point is why such functionality isn't in git client already when he has all pieces of information already and ability to do all of that. Maybe I am missing some reason behind that but to me it looks like missing feature.

Thank you for your answers,
Vojtech Vladyka

Re: Removing fully-merged branches

[Junio C Hamano]

Vojtěch Vladyka <Vojtech.Vladyka@velux.com> writes:

> I know there are command chains doing this job usually starting
> with git branch --merged followed by grep and ending with git
> branch -d but my point is why such functionality isn't in git
> client already when he has all pieces of information already and
> ability to do all of that. Maybe I am missing some reason behind
> that but to me it looks like missing feature.

I think the primary reason behind it is because the way to "prune"
(i.e. you gave a good outline yourself in your messaage) is
trivially discoverable and people can do so with more flexibility
than a hardcoded "remove every branch that does not have commits
that does not exist in the $master branch".  Add to it the fact that
those who want to make it into a "native" feature haven't produced
any usable design yet [*].

In my repository that is used to develop Git itself, for example,
"remove all branches that are merged to 'master'" is not something
I'd ever want to run, as it will lose all the maintenance tracks (it
is a rule in this project that older maintenance branches are subset
of the newer ones and the 'master' branch), and removing all topic
branches that are merged to 'maint' would not get rid of as many
stale topic branches that are already merged to 'master' and will
never be merged down to 'maint' or older maintenance tracks, so for
such a feature to be useful, I'd need to be able to express
something like:

 - If a branch is not a topic branch (identifyable by having
   two-level names like vv/topic), do not touch it.

 - If a topic branch is based on 'maint' but not merged there yet,
   keep it.

 - If a topic branch is merged to 'master' and in a tagged version
   (identifyable by having a signed tag whose name does not end with
   -rcX), lose it.

So that a bugfix topic that has appeared in the last feature release
can be kept to later be merged down to older maintenance tracks.


[Footnote]

 * As far as I remember, the message I am responding to might be the
   first to explicitly ask for such a feature.

RE: Removing fully-merged branches

[Vojtěch Vladyka]

Thank you very much for clarifying this.  I thought there would be some reason behind but you are first who presented exact reasoning.

Anyway, I take that thrown glove and take a look at git sources and how to contribute. Maybe I can come up with something useful.

Have a nice day,
Vojtech

-----Original Message-----
From: Junio C Hamano <gitster@pobox.com> 
Sent: Thursday, June 10, 2021 3:41 AM
To: Vojtěch Vladyka <Vojtech.Vladyka@velux.com>
Cc: git@vger.kernel.org
Subject: Re: Removing fully-merged branches

Attention! This message originated outside of VELUX.


Vojtěch Vladyka <Vojtech.Vladyka@velux.com> writes:

> I know there are command chains doing this job usually starting with 
> git branch --merged followed by grep and ending with git branch -d but 
> my point is why such functionality isn't in git client already when he 
> has all pieces of information already and ability to do all of that. 
> Maybe I am missing some reason behind that but to me it looks like 
> missing feature.

I think the primary reason behind it is because the way to "prune"
(i.e. you gave a good outline yourself in your messaage) is trivially discoverable and people can do so with more flexibility than a hardcoded "remove every branch that does not have commits that does not exist in the $master branch".  Add to it the fact that those who want to make it into a "native" feature haven't produced any usable design yet [*].

In my repository that is used to develop Git itself, for example, "remove all branches that are merged to 'master'" is not something I'd ever want to run, as it will lose all the maintenance tracks (it is a rule in this project that older maintenance branches are subset of the newer ones and the 'master' branch), and removing all topic branches that are merged to 'maint' would not get rid of as many stale topic branches that are already merged to 'master' and will never be merged down to 'maint' or older maintenance tracks, so for such a feature to be useful, I'd need to be able to express something like:

 - If a branch is not a topic branch (identifyable by having
   two-level names like vv/topic), do not touch it.

 - If a topic branch is based on 'maint' but not merged there yet,
   keep it.

 - If a topic branch is merged to 'master' and in a tagged version
   (identifyable by having a signed tag whose name does not end with
   -rcX), lose it.

So that a bugfix topic that has appeared in the last feature release can be kept to later be merged down to older maintenance tracks.


[Footnote]

 * As far as I remember, the message I am responding to might be the
   first to explicitly ask for such a feature.