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@xxxxxxxxx> Sent: Thursday, June 10, 2021 3:41 AM To: Vojtěch Vladyka <Vojtech.Vladyka@xxxxxxxxx> Cc: git@xxxxxxxxxxxxxxx Subject: Re: Removing fully-merged branches Attention! This message originated outside of VELUX. Vojtěch Vladyka <Vojtech.Vladyka@xxxxxxxxx> 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.
