{"thread":{"id":"55886","subject":"Removing fully-merged branches","startedAt":"2021-06-09T09:05:31Z","lastAt":"2021-06-10T05:07:26Z","messageCount":3,"participants":["Vojtěch Vladyka","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"426866","messageId":"DBAPR05MB7510441970BA87A456B8C0D8EC369@DBAPR05MB7510.eurprd05.prod.outlook.com","threadId":"55886","inReplyTo":null,"subject":"Removing fully-merged branches","fromName":"Vojtěch Vladyka","fromEmail":"vojtech.vladyka@velux.com","sentAt":"2021-06-09T09:05:22Z","receivedAt":"2021-06-09T09:05:31Z","isPatch":false,"sender":{"key":"vojtech.vladyka@velux.com","avatar":null},"body":"Hello!\n\nPermanent issue popping up in our team is removing local branches which were fully merged. \n\nI 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.\n\nThank you for your answers,\nVojtech Vladyka\n"},{"id":"426939","messageId":"xmqqwnr2h4xn.fsf@gitster.g","threadId":"55886","inReplyTo":"DBAPR05MB7510441970BA87A456B8C0D8EC369@DBAPR05MB7510.eurprd05.prod.outlook.com","subject":"Re: Removing fully-merged branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-10T01:41:24Z","receivedAt":"2021-06-10T01:41:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Vojtěch Vladyka <Vojtech.Vladyka@velux.com> writes:\n\n> I know there are command chains doing this job usually starting\n> with git branch --merged followed by grep and ending with git\n> branch -d but my point is why such functionality isn't in git\n> client already when he has all pieces of information already and\n> ability to do all of that. Maybe I am missing some reason behind\n> that but to me it looks like missing feature.\n\nI think the primary reason behind it is because the way to \"prune\"\n(i.e. you gave a good outline yourself in your messaage) is\ntrivially discoverable and people can do so with more flexibility\nthan a hardcoded \"remove every branch that does not have commits\nthat does not exist in the $master branch\".  Add to it the fact that\nthose who want to make it into a \"native\" feature haven't produced\nany usable design yet [*].\n\nIn my repository that is used to develop Git itself, for example,\n\"remove all branches that are merged to 'master'\" is not something\nI'd ever want to run, as it will lose all the maintenance tracks (it\nis a rule in this project that older maintenance branches are subset\nof the newer ones and the 'master' branch), and removing all topic\nbranches that are merged to 'maint' would not get rid of as many\nstale topic branches that are already merged to 'master' and will\nnever be merged down to 'maint' or older maintenance tracks, so for\nsuch a feature to be useful, I'd need to be able to express\nsomething like:\n\n - If a branch is not a topic branch (identifyable by having\n   two-level names like vv/topic), do not touch it.\n\n - If a topic branch is based on 'maint' but not merged there yet,\n   keep it.\n\n - If a topic branch is merged to 'master' and in a tagged version\n   (identifyable by having a signed tag whose name does not end with\n   -rcX), lose it.\n\nSo that a bugfix topic that has appeared in the last feature release\ncan be kept to later be merged down to older maintenance tracks.\n\n\n[Footnote]\n\n * As far as I remember, the message I am responding to might be the\n   first to explicitly ask for such a feature.\n"},{"id":"426945","messageId":"DBAPR05MB7510739C8AD273CD13FAD0DCEC359@DBAPR05MB7510.eurprd05.prod.outlook.com","threadId":"55886","inReplyTo":"xmqqwnr2h4xn.fsf@gitster.g","subject":"RE: Removing fully-merged branches","fromName":"Vojtěch Vladyka","fromEmail":"vojtech.vladyka@velux.com","sentAt":"2021-06-10T05:07:21Z","receivedAt":"2021-06-10T05:07:26Z","isPatch":false,"sender":{"key":"vojtech.vladyka@velux.com","avatar":null},"body":"Thank you very much for clarifying this.  I thought there would be some reason behind but you are first who presented exact reasoning.\n\nAnyway, I take that thrown glove and take a look at git sources and how to contribute. Maybe I can come up with something useful.\n\nHave a nice day,\nVojtech\n\n-----Original Message-----\nFrom: Junio C Hamano <gitster@pobox.com> \nSent: Thursday, June 10, 2021 3:41 AM\nTo: Vojtěch Vladyka <Vojtech.Vladyka@velux.com>\nCc: git@vger.kernel.org\nSubject: Re: Removing fully-merged branches\n\nAttention! This message originated outside of VELUX.\n\n\nVojtěch Vladyka <Vojtech.Vladyka@velux.com> writes:\n\n> I know there are command chains doing this job usually starting with \n> git branch --merged followed by grep and ending with git branch -d but \n> my point is why such functionality isn't in git client already when he \n> has all pieces of information already and ability to do all of that. \n> Maybe I am missing some reason behind that but to me it looks like \n> missing feature.\n\nI think the primary reason behind it is because the way to \"prune\"\n(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 [*].\n\nIn 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:\n\n - If a branch is not a topic branch (identifyable by having\n   two-level names like vv/topic), do not touch it.\n\n - If a topic branch is based on 'maint' but not merged there yet,\n   keep it.\n\n - If a topic branch is merged to 'master' and in a tagged version\n   (identifyable by having a signed tag whose name does not end with\n   -rcX), lose it.\n\nSo that a bugfix topic that has appeared in the last feature release can be kept to later be merged down to older maintenance tracks.\n\n\n[Footnote]\n\n * As far as I remember, the message I am responding to might be the\n   first to explicitly ask for such a feature.\n"}]}