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
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
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,
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
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.2We 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
Julien Pauli jpauli@php.net 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
Julien Pauli jpauli@php.net 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
-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
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
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
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
--
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).
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 WilliamsCould 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
--
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).
Hi all,
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.
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
Hi all,
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.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.