# Cleanup of old remote branches - Thread: https://externals.io/message/69934 - Original archive: https://news-web.php.net/php.internals/69934 - Started by Julien Pauli on 2013-10-29T10:56:35+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #69934 — Julien Pauli — 2013-10-29T10:56:35+00:00 URL: https://externals.io/message/69934#69934 Hi internals. Doing a git branch --all , I notice that we still carry very old branches (back from the svn or even cvs times). Here is the list : remotes/origin/experimental/5.2-WITH_DRCP remotes/origin/experimental/5.3-FPM remotes/origin/experimental/RETURN_REF remotes/origin/experimental/ZendEngine2 remotes/origin/experimental/apache_hooks remotes/origin/experimental/first_unicode_implementation remotes/origin/experimental/lemon remotes/origin/experimental/namespaces remotes/origin/experimental/new_apache_hooks remotes/origin/experimental/new_ui_api remotes/origin/experimental/newoperator remotes/origin/experimental/phar_tar remotes/origin/experimental/pre_new_hash_func remotes/origin/experimental/rand_redesign remotes/origin/experimental/the_5_4_that_isnt_5_4 remotes/origin/experimental/threaded remotes/origin/experimental/with_scalar_types remotes/origin/experimental/zts_stdc_scanners remotes/origin/experimetnal/RETURN_REF_PATCH remotes/origin/immutable-date remotes/origin/master remotes/origin/migration/EXPERIMENTAL remotes/origin/migration/INITIAL remotes/origin/migration/RELEASE_1_0_0 remotes/origin/migration/sqlite-start remotes/origin/migration/unlabaled-1.1.2 remotes/origin/migration/unlabaled-1.29.2 remotes/origin/migration/unlabaled-1.3.2 remotes/origin/migration/unlabaled-1.67.2 We don't need git space, right ; but I think we need some cleanup to keep consistency. While I know "immutable-date" or even "lemon" could still be reworked on in the future, I personnaly have absolutely no clue about "migration/unlabaled-1.67.2" for example. "experimental/the_5_4_that_isnt_5_4" is funny as well, I guess it's a try for someone, I haven't diffed it anyway. I assume some of our remote branches are both old and useless nowadays. Could we make a list of the remote branches we really don't need anymore, and clean them up ? Thx Julien Pauli --- ## #69935 — Yasuo Ohgaki — 2013-10-29T11:09:33+00:00 URL: https://externals.io/message/69934#69935 · In reply to: #69934 Hi Julien, > We don't need git space, right ; but I think we need some cleanup to keep > consistency. > While I know "immutable-date" or even "lemon" could still be reworked on in > the future, I personnaly have absolutely no clue about > "migration/unlabaled-1.67.2" for example. > "experimental/the_5_4_that_isnt_5_4" is funny as well, I guess it's a try > for someone, I haven't diffed it anyway. > I assume some of our remote branches are both old and useless nowadays. > > Could we make a list of the remote branches we really don't need anymore, > and clean them up ? > There are too many branches. +1 for removing fully merged branches. No point to keep them. +1 for removing discarded branches. +1 for old work in progress branches. If anyone need them, we can keep them locally. If we decided to keep some of them, renaming is needed at least. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #69938 — Joe Watkins — 2013-10-29T11:18:36+00:00 URL: https://externals.io/message/69934#69938 · In reply to: #69934 > Hi internals. > > Doing a git branch --all , I notice that we still carry very old branches > (back from the svn or even cvs times). > > Here is the list : > > remotes/origin/experimental/5.2-WITH_DRCP > remotes/origin/experimental/5.3-FPM > remotes/origin/experimental/RETURN_REF > remotes/origin/experimental/ZendEngine2 > remotes/origin/experimental/apache_hooks > remotes/origin/experimental/first_unicode_implementation > remotes/origin/experimental/lemon > remotes/origin/experimental/namespaces > remotes/origin/experimental/new_apache_hooks > remotes/origin/experimental/new_ui_api > remotes/origin/experimental/newoperator > remotes/origin/experimental/phar_tar > remotes/origin/experimental/pre_new_hash_func > remotes/origin/experimental/rand_redesign > remotes/origin/experimental/the_5_4_that_isnt_5_4 > remotes/origin/experimental/threaded > remotes/origin/experimental/with_scalar_types > remotes/origin/experimental/zts_stdc_scanners > remotes/origin/experimetnal/RETURN_REF_PATCH > remotes/origin/immutable-date > remotes/origin/master > remotes/origin/migration/EXPERIMENTAL > remotes/origin/migration/INITIAL > remotes/origin/migration/RELEASE_1_0_0 > remotes/origin/migration/sqlite-start > remotes/origin/migration/unlabaled-1.1.2 > remotes/origin/migration/unlabaled-1.29.2 > remotes/origin/migration/unlabaled-1.3.2 > remotes/origin/migration/unlabaled-1.67.2 > > We don't need git space, right ; but I think we need some cleanup to keep > consistency. > While I know "immutable-date" or even "lemon" could still be reworked on in > the future, I personnaly have absolutely no clue about > "migration/unlabaled-1.67.2" for example. > "experimental/the_5_4_that_isnt_5_4" is funny as well, I guess it's a try > for someone, I haven't diffed it anyway. > I assume some of our remote branches are both old and useless nowadays. > > Could we make a list of the remote branches we really don't need anymore, > and clean them up ? > > Thx > > Julien Pauli > Pointless to keep merged ones ... Don't remove anything interesting though, please ... Or if it must be removed, can we have a php-siberia ?? Cheers Joe --- ## #69964 — Julien Pauli — 2013-10-30T10:47:55+00:00 URL: https://externals.io/message/69934#69964 · In reply to: #69935 > Hi Julien, > > > > > […] > > There are too many branches. > > +1 for removing fully merged branches. No point to keep them. > +1 for removing discarded branches. > +1 for old work in progress branches. If anyone need them, we can keep > them locally. > > If we decided to keep some of them, renaming is needed at least. > > Regards, > I won't remove anything by myself. Im asking everyone to make a list of branches , and what action we should take about them (mainly : remove, or perhaps archive somewhere for some of them). Julien Pauli --- ## #69967 — David Soria Parra — 2013-10-30T15:55:45+00:00 URL: https://externals.io/message/69934#69967 · In reply to: #69934 Julien Pauli schrieb: > Could we make a list of the remote branches we really don't need anymore, > and clean them up ? This was discussed when we moved to git. If we delete the branches eventual commits will get lost. They honestly don't hurt at all unless you are super aestetic about it in which case you don't want to look at git branch -a anyway. Therefore I see no reason to remove them except for killing parts of PHP's version control system history. -1 for me. It's obv okay for branches that got merged. David --- ## #69968 — leafnode@gmail.com — 2013-10-30T16:03:52+00:00 URL: https://externals.io/message/69934#69968 · In reply to: #69967 > Julien Pauli schrieb: > > […] > This was discussed when we moved to git. If we delete the branches eventual > commits will get lost. They honestly don't hurt at all unless you are super > aestetic about it in which case you don't want to look at git branch -a anyway. > Therefore I see no reason to remove them except for killing parts of PHP's > version control system history. > > -1 for me. > > It's obv okay for branches that got merged. > > David -1 as well. In git most branches don't take much space if any (branch is just a pointer to a commit - if this commit is also in another branch, no data is duplicated). --Leszek --- ## #69969 — Adam Harvey — 2013-10-30T16:58:52+00:00 URL: https://externals.io/message/69934#69969 · In reply to: #69934 > Could we make a list of the remote branches we really don't need anymore, > and clean them up ? Also -1 here. Command line tab completion and GitHub's branch filtering UI basically make the cognitive overhead of dealing with this minimal, and having a full history is important. Adam --- ## #69975 — Robert Williams — 2013-10-31T03:32:58+00:00 URL: https://externals.io/message/69934#69975 · In reply to: #69969 In Subversion, nothing is ever really deleted. If you delete a branch, it still exists in the repository's history, and it can easily be resurrected with history intact. Is this not the way git works? (I'm obviously not real familiar with git.) -- Bob Williams > > > > […] > > Also -1 here. Command line tab completion and GitHub's branch > filtering UI basically make the cognitive overhead of dealing with > this minimal, and having a full history is important. > > Adam > > -- > > > Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). --- ## #69976 — Yasuo Ohgaki — 2013-10-31T04:15:57+00:00 URL: https://externals.io/message/69934#69976 · In reply to: #69969 Hi all, > > > […] > > Also -1 here. Command line tab completion and GitHub's branch > filtering UI basically make the cognitive overhead of dealing with > this minimal, and having a full history is important. Unfortunately, we already lost important source code history in our git. Checkout PHP 4.X branches, then you'll see there aren't any Zend dirs. If we should keep current git data, how about create repository called git-lagacy.php.net? (And add missing Zend dirs for older PHP in there) Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #69982 — timwolla@bastelstu.be — 2013-10-31T10:10:13+00:00 URL: https://externals.io/message/69934#69982 · In reply to: #69975 In git a branch simply is a pointer to a commit. If a branch is deleted the commit wil stay in the repository for the near future, but it will eventually be deleted (by git prune / git gc) as it is not referenced by anything. Tim > In Subversion, nothing is ever really deleted. If you delete a branch, it still exists in the repository's history, and it can easily be resurrected with history intact. Is this not the way git works? (I'm obviously not real familiar with git.) > > -- > Bob Williams > > > […] > > Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). --- ## #69985 — rparker@yamiko.org — 2013-10-31T16:35:53+00:00 URL: https://externals.io/message/69934#69985 · In reply to: #69976 > Hi all, > > > > > […] > > > Unfortunately, we already lost important source code history in our > git. > Checkout PHP 4.X branches, then you'll see there aren't any Zend dirs. > > If we should keep current git data, how about create repository called > git-lagacy.php.net? (And add missing Zend dirs for older PHP in there) > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net +1 for this idea. We need the history but the brances should be cleaned up.