Mailing List Archive

What's the point of even having a tag for "branch_8x", "branch_7x" etc.?
Their very existence was fundamentally to commit code to, and were
constantly moving forward as work happens. They will still exist in
lucene-solr repo, so "no history is lost" will be true as well.
Having tags for actual releases (e.g. for 8.8, 8.7, etc.) is great for
doing quick IDE comparisons to see how code changed.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Mon, Mar 15, 2021 at 9:50 AM Jan Høydahl <jan.asf@cominvent.com> wrote:

> Hi,
>
> With the new lucene.git repo up and running, we (Uwe, Dawid and I) like to
> get rid of some clutter.
>
> We discussed on Slack and later her on list[1] the option of pruning all
> the 112 old branches. It makes no sense to keep stale branch_x_y branches
> in lucene.git repo, as any future 8.x or 7.x release will happen from
> lucene-solr.git, so keeping them as branches in lucene.git is duplication
> and only gives room for developer mistakes. If branch_8_8 does not exist in
> lucene.git repo, noone will push to it, and rather remember to make a patch
> for lucene-solr.git instead.
>
> So my plan is to remove all branches in the new lucene.git repostiory and
> leave only the "main" branch. We just did this in solr.git repo (SOLR-15253
> [3]).
>
> We'll do this by replacing each branch with a git tag, e.g. branch_8x will
> be replaced with tag history/branches/lucene-solr/branch_8x. This is the
> same procedure we did when moving from svn to git. *No history is lost!*
>
> The script I intend to run in a few days is attached on LUCENE-9835 [2].
>
> *Should you have a work-in-progress on a branch currently scheduled for
> removal, please reply here to excempt it from removal until it is merged.*
>
> After the removal you can run "git fetch --prune origin" to not see the
> remote branches in your local clone.
>
> PS: The lucene-solr.git repo, where 8.x development continues, will not be
> affected.
>
> [1]
> https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41%40%3Cdev.lucene.apache.org%3E
> <https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41@%3Cdev.lucene.apache.org%3E>
> [2] https://issues.apache.org/jira/browse/LUCENE-9835
> [3] https://issues.apache.org/jira/browse/SOLR-15253
>

Deleting unneeded tags is easy, so starting with the automatied script is fine.



I agree to remove those “orking” branches/tags in the lucene and solr repos. Once done, the disk space may reduce, as “git gc” will remove all refs.



Uwe



-----

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: uwe@thetaphi.de



From: David Smiley <dsmiley@apache.org>
Sent: Monday, March 15, 2021 3:30 PM
To: lucene-dev <dev@lucene.apache.org>
Subject: Re: [NOTICE] Old git branches will be pruned (in lucene.git repo)



What's the point of even having a tag for "branch_8x", "branch_7x" etc.? Their very existence was fundamentally to commit code to, and were constantly moving forward as work happens. They will still exist in lucene-solr repo, so "no history is lost" will be true as well.

Having tags for actual releases (e.g. for 8.8, 8.7, etc.) is great for doing quick IDE comparisons to see how code changed.




~ David Smiley

Apache Lucene/Solr Search Developer

http://www.linkedin.com/in/davidwsmiley





On Mon, Mar 15, 2021 at 9:50 AM Jan Høydahl <jan.asf@cominvent.com <mailto:jan.asf@cominvent.com> > wrote:

Hi,



With the new lucene.git repo up and running, we (Uwe, Dawid and I) like to get rid of some clutter.



We discussed on Slack and later her on list[1] the option of pruning all the 112 old branches. It makes no sense to keep stale branch_x_y branches in lucene.git repo, as any future 8.x or 7.x release will happen from lucene-solr.git, so keeping them as branches in lucene.git is duplication and only gives room for developer mistakes. If branch_8_8 does not exist in lucene.git repo, noone will push to it, and rather remember to make a patch for lucene-solr.git instead.



So my plan is to remove all branches in the new lucene.git repostiory and leave only the "main" branch. We just did this in solr.git repo (SOLR-15253 [3]).



We'll do this by replacing each branch with a git tag, e.g. branch_8x will be replaced with tag history/branches/lucene-solr/branch_8x. This is the same procedure we did when moving from svn to git. No history is lost!



The script I intend to run in a few days is attached on LUCENE-9835 [2].



Should you have a work-in-progress on a branch currently scheduled for removal, please reply here to excempt it from removal until it is merged.

After the removal you can run "git fetch --prune origin" to not see the remote branches in your local clone.

PS: The lucene-solr.git repo, where 8.x development continues, will not be affected.



[1] https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41%40%3Cdev.lucene.apache.org%3E <https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41@%3Cdev.lucene.apache.org%3E>

[2] https://issues.apache.org/jira/browse/LUCENE-9835

[3] https://issues.apache.org/jira/browse/SOLR-15253

This time around I'll have Infra mute the emails to commits list during the bulk change.
I'll probably get around to this on Friday or Monday. If anyone wants to grab this and do it earlier then that's ok with me.

Jan

> 15. mar. 2021 kl. 16:06 skrev Uwe Schindler <uwe@thetaphi.de>:
>
> Deleting unneeded tags is easy, so starting with the automatied script is fine.
>
> I agree to remove those “orking” branches/tags in the lucene and solr repos. Once done, the disk space may reduce, as “git gc” will remove all refs.
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>
> eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
>
> From: David Smiley <dsmiley@apache.org>
> Sent: Monday, March 15, 2021 3:30 PM
> To: lucene-dev <dev@lucene.apache.org>
> Subject: Re: [NOTICE] Old git branches will be pruned (in lucene.git repo)
>
> What's the point of even having a tag for "branch_8x", "branch_7x" etc.? Their very existence was fundamentally to commit code to, and were constantly moving forward as work happens. They will still exist in lucene-solr repo, so "no history is lost" will be true as well.
> Having tags for actual releases (e.g. for 8.8, 8.7, etc.) is great for doing quick IDE comparisons to see how code changed.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>
>
> On Mon, Mar 15, 2021 at 9:50 AM Jan Høydahl <jan.asf@cominvent.com <mailto:jan.asf@cominvent.com>> wrote:
>> Hi,
>>
>> With the new lucene.git repo up and running, we (Uwe, Dawid and I) like to get rid of some clutter.
>>
>> We discussed on Slack and later her on list[1] the option of pruning all the 112 old branches. It makes no sense to keep stale branch_x_y branches in lucene.git repo, as any future 8.x or 7.x release will happen from lucene-solr.git, so keeping them as branches in lucene.git is duplication and only gives room for developer mistakes. If branch_8_8 does not exist in lucene.git repo, noone will push to it, and rather remember to make a patch for lucene-solr.git instead.
>>
>> So my plan is to remove all branches in the new lucene.git repostiory and leave only the "main" branch. We just did this in solr.git repo (SOLR-15253 [3]).
>>
>> We'll do this by replacing each branch with a git tag, e.g. branch_8x will be replaced with tag history/branches/lucene-solr/branch_8x. This is the same procedure we did when moving from svn to git. No history is lost!
>>
>> The script I intend to run in a few days is attached on LUCENE-9835 [2].
>>
>> Should you have a work-in-progress on a branch currently scheduled for removal, please reply here to excempt it from removal until it is merged.
>>
>> After the removal you can run "git fetch --prune origin" to not see the remote branches in your local clone.
>>
>> PS: The lucene-solr.git repo, where 8.x development continues, will not be affected.
>>
>> [1] https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41%40%3Cdev.lucene.apache.org%3E <https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41@%3Cdev.lucene.apache.org%3E>
>> [2] https://issues.apache.org/jira/browse/LUCENE-9835 <https://issues.apache.org/jira/browse/LUCENE-9835>
>> [3] https://issues.apache.org/jira/browse/SOLR-15253 <https://issues.apache.org/jira/browse/SOLR-15253>

Hi all,

Today, all the old git branches in lucene.git are gone.

If you like to sync up your local git checkout so you don't see those phantom branches, please run this command in your local checkout:

git fetch --prune origin

Jan

> 16. mar. 2021 kl. 16:04 skrev Jan Høydahl <jan.asf@cominvent.com>:
>
> This time around I'll have Infra mute the emails to commits list during the bulk change.
> I'll probably get around to this on Friday or Monday. If anyone wants to grab this and do it earlier then that's ok with me.
>
> Jan
>
>> 15. mar. 2021 kl. 16:06 skrev Uwe Schindler <uwe@thetaphi.de <mailto:uwe@thetaphi.de>>:
>>
>> Deleting unneeded tags is easy, so starting with the automatied script is fine.
>>
>> I agree to remove those “orking” branches/tags in the lucene and solr repos. Once done, the disk space may reduce, as “git gc” will remove all refs.
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
>>
>> From: David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>>
>> Sent: Monday, March 15, 2021 3:30 PM
>> To: lucene-dev <dev@lucene.apache.org <mailto:dev@lucene.apache.org>>
>> Subject: Re: [NOTICE] Old git branches will be pruned (in lucene.git repo)
>>
>> What's the point of even having a tag for "branch_8x", "branch_7x" etc.? Their very existence was fundamentally to commit code to, and were constantly moving forward as work happens. They will still exist in lucene-solr repo, so "no history is lost" will be true as well.
>> Having tags for actual releases (e.g. for 8.8, 8.7, etc.) is great for doing quick IDE comparisons to see how code changed.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>
>>
>> On Mon, Mar 15, 2021 at 9:50 AM Jan Høydahl <jan.asf@cominvent.com <mailto:jan.asf@cominvent.com>> wrote:
>>> Hi,
>>>
>>> With the new lucene.git repo up and running, we (Uwe, Dawid and I) like to get rid of some clutter.
>>>
>>> We discussed on Slack and later her on list[1] the option of pruning all the 112 old branches. It makes no sense to keep stale branch_x_y branches in lucene.git repo, as any future 8.x or 7.x release will happen from lucene-solr.git, so keeping them as branches in lucene.git is duplication and only gives room for developer mistakes. If branch_8_8 does not exist in lucene.git repo, noone will push to it, and rather remember to make a patch for lucene-solr.git instead.
>>>
>>> So my plan is to remove all branches in the new lucene.git repostiory and leave only the "main" branch. We just did this in solr.git repo (SOLR-15253 [3]).
>>>
>>> We'll do this by replacing each branch with a git tag, e.g. branch_8x will be replaced with tag history/branches/lucene-solr/branch_8x. This is the same procedure we did when moving from svn to git. No history is lost!
>>>
>>> The script I intend to run in a few days is attached on LUCENE-9835 [2].
>>>
>>> Should you have a work-in-progress on a branch currently scheduled for removal, please reply here to excempt it from removal until it is merged.
>>>
>>> After the removal you can run "git fetch --prune origin" to not see the remote branches in your local clone.
>>>
>>> PS: The lucene-solr.git repo, where 8.x development continues, will not be affected.
>>>
>>> [1] https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41%40%3Cdev.lucene.apache.org%3E <https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41@%3Cdev.lucene.apache.org%3E>
>>> [2] https://issues.apache.org/jira/browse/LUCENE-9835 <https://issues.apache.org/jira/browse/LUCENE-9835>
>>> [3] https://issues.apache.org/jira/browse/SOLR-15253 <https://issues.apache.org/jira/browse/SOLR-15253>