git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* Removing fully-merged branches
@ 2021-06-09  9:05 Vojtěch Vladyka
  2021-06-10  1:41 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Vojtěch Vladyka @ 2021-06-09  9:05 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Removing fully-merged branches
  2021-06-09  9:05 Removing fully-merged branches Vojtěch Vladyka
@ 2021-06-10  1:41 ` Junio C Hamano
  2021-06-10  5:07   ` Vojtěch Vladyka
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2021-06-10  1:41 UTC (permalink / raw)
  To: Vojtěch Vladyka; +Cc: git

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: Removing fully-merged branches
  2021-06-10  1:41 ` Junio C Hamano
@ 2021-06-10  5:07   ` Vojtěch Vladyka
  0 siblings, 0 replies; 3+ messages in thread
From: Vojtěch Vladyka @ 2021-06-10  5:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-06-10  5:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-09  9:05 Removing fully-merged branches Vojtěch Vladyka
2021-06-10  1:41 ` Junio C Hamano
2021-06-10  5:07   ` Vojtěch Vladyka

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

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

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git