You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Dawid Weiss <da...@gmail.com> on 2020/12/17 11:30:51 UTC

[IMPORTANT] Automatic code reformatting (LUCENE-9564)

Hey everyone,

Sorry it took me a while but I wanted to get back to LUCENE-9564 and
applying an automated (and non-configurable) code formatter. This will
cause some disruption to all existing branches and patches so I'd like
to make the process as simple as possible by doing the following:

1) adding spotless (formatter infrastructure) to gradle build on
master. This literally changes nothing as initially it wouldn't be
including any sources.

2) progressively go package-by-package and project-by-project and
reformat code, then commit it back to master. Splitting into smaller
work pieces is simpler and perhaps others may help in to review if the
formatter didn't screw up anything (I'll start!).

3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted,
don't despair. It's actually pretty easy to recover -- all you'd need
to do would be to cherry pick the initial spotless commit from (1),
then take the up-to-date content of spotless.gradle and just run this
on your branch:

./gradlew tidy

This should reformat the same packages and the same code as on master.
If nothing has changed, the diff between your branch and master should
be empty. If something *did* change, the reformatted code should still
cleanly show just the lines you've changed.

Commit the changes to your branch and you should be fine.

Does this sound like a plan? I'd like to start with the initial few
packages from the core and a few other projects so that folks can see
what the process looks like - then I'd really like a helping hand with
the rest. I'm only concerned with Lucene at the moment.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Re: [IMPORTANT] Automatic code reformatting (LUCENE-9564)

Posted by Dawid Weiss <da...@gmail.com>.
I am aware of this and I don't intend to touch Solr at the moment.


Dawid

On Thu, Dec 17, 2020 at 5:10 PM Ishan Chattopadhyaya
<ic...@gmail.com> wrote:
>
> Let's please leave the Solr side until 8.8 is out. Some big changes are in flight and I don't want to waste time with the merges to the various branches.
>
> On Thu, 17 Dec, 2020, 8:43 pm Timothy Potter, <th...@gmail.com> wrote:
>>
>> Sounds great Dawid! And sorely needed in this project, thanks for taking this on. I'll do as much as I can on the Solr side ;-)
>>
>> Cheers,
>> Tim
>>
>> On Thu, Dec 17, 2020 at 4:31 AM Dawid Weiss <da...@gmail.com> wrote:
>>>
>>> Hey everyone,
>>>
>>> Sorry it took me a while but I wanted to get back to LUCENE-9564 and
>>> applying an automated (and non-configurable) code formatter. This will
>>> cause some disruption to all existing branches and patches so I'd like
>>> to make the process as simple as possible by doing the following:
>>>
>>> 1) adding spotless (formatter infrastructure) to gradle build on
>>> master. This literally changes nothing as initially it wouldn't be
>>> including any sources.
>>>
>>> 2) progressively go package-by-package and project-by-project and
>>> reformat code, then commit it back to master. Splitting into smaller
>>> work pieces is simpler and perhaps others may help in to review if the
>>> formatter didn't screw up anything (I'll start!).
>>>
>>> 3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted,
>>> don't despair. It's actually pretty easy to recover -- all you'd need
>>> to do would be to cherry pick the initial spotless commit from (1),
>>> then take the up-to-date content of spotless.gradle and just run this
>>> on your branch:
>>>
>>> ./gradlew tidy
>>>
>>> This should reformat the same packages and the same code as on master.
>>> If nothing has changed, the diff between your branch and master should
>>> be empty. If something *did* change, the reformatted code should still
>>> cleanly show just the lines you've changed.
>>>
>>> Commit the changes to your branch and you should be fine.
>>>
>>> Does this sound like a plan? I'd like to start with the initial few
>>> packages from the core and a few other projects so that folks can see
>>> what the process looks like - then I'd really like a helping hand with
>>> the rest. I'm only concerned with Lucene at the moment.
>>>
>>> Dawid
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Re: [IMPORTANT] Automatic code reformatting (LUCENE-9564)

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Let's please leave the Solr side until 8.8 is out. Some big changes are in
flight and I don't want to waste time with the merges to the various
branches.

On Thu, 17 Dec, 2020, 8:43 pm Timothy Potter, <th...@gmail.com> wrote:

> Sounds great Dawid! And sorely needed in this project, thanks for taking
> this on. I'll do as much as I can on the Solr side ;-)
>
> Cheers,
> Tim
>
> On Thu, Dec 17, 2020 at 4:31 AM Dawid Weiss <da...@gmail.com> wrote:
>
>> Hey everyone,
>>
>> Sorry it took me a while but I wanted to get back to LUCENE-9564 and
>> applying an automated (and non-configurable) code formatter. This will
>> cause some disruption to all existing branches and patches so I'd like
>> to make the process as simple as possible by doing the following:
>>
>> 1) adding spotless (formatter infrastructure) to gradle build on
>> master. This literally changes nothing as initially it wouldn't be
>> including any sources.
>>
>> 2) progressively go package-by-package and project-by-project and
>> reformat code, then commit it back to master. Splitting into smaller
>> work pieces is simpler and perhaps others may help in to review if the
>> formatter didn't screw up anything (I'll start!).
>>
>> 3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted,
>> don't despair. It's actually pretty easy to recover -- all you'd need
>> to do would be to cherry pick the initial spotless commit from (1),
>> then take the up-to-date content of spotless.gradle and just run this
>> on your branch:
>>
>> ./gradlew tidy
>>
>> This should reformat the same packages and the same code as on master.
>> If nothing has changed, the diff between your branch and master should
>> be empty. If something *did* change, the reformatted code should still
>> cleanly show just the lines you've changed.
>>
>> Commit the changes to your branch and you should be fine.
>>
>> Does this sound like a plan? I'd like to start with the initial few
>> packages from the core and a few other projects so that folks can see
>> what the process looks like - then I'd really like a helping hand with
>> the rest. I'm only concerned with Lucene at the moment.
>>
>> Dawid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

Re: [IMPORTANT] Automatic code reformatting (LUCENE-9564)

Posted by Timothy Potter <th...@gmail.com>.
Sounds great Dawid! And sorely needed in this project, thanks for taking
this on. I'll do as much as I can on the Solr side ;-)

Cheers,
Tim

On Thu, Dec 17, 2020 at 4:31 AM Dawid Weiss <da...@gmail.com> wrote:

> Hey everyone,
>
> Sorry it took me a while but I wanted to get back to LUCENE-9564 and
> applying an automated (and non-configurable) code formatter. This will
> cause some disruption to all existing branches and patches so I'd like
> to make the process as simple as possible by doing the following:
>
> 1) adding spotless (formatter infrastructure) to gradle build on
> master. This literally changes nothing as initially it wouldn't be
> including any sources.
>
> 2) progressively go package-by-package and project-by-project and
> reformat code, then commit it back to master. Splitting into smaller
> work pieces is simpler and perhaps others may help in to review if the
> formatter didn't screw up anything (I'll start!).
>
> 3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted,
> don't despair. It's actually pretty easy to recover -- all you'd need
> to do would be to cherry pick the initial spotless commit from (1),
> then take the up-to-date content of spotless.gradle and just run this
> on your branch:
>
> ./gradlew tidy
>
> This should reformat the same packages and the same code as on master.
> If nothing has changed, the diff between your branch and master should
> be empty. If something *did* change, the reformatted code should still
> cleanly show just the lines you've changed.
>
> Commit the changes to your branch and you should be fine.
>
> Does this sound like a plan? I'd like to start with the initial few
> packages from the core and a few other projects so that folks can see
> what the process looks like - then I'd really like a helping hand with
> the rest. I'm only concerned with Lucene at the moment.
>
> Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>