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/22 13:55:40 UTC
Code reformatting
Hi Mike, Ignacio,
Just wanted to let you know that I wanted to go through the rest of
lucene-core reformatting soon-ish (I've done a lot on the branch
already and a subset of packages ended on master too).
This will touch packages which you've been working on recently. I
don't think it'll be a problem, even if you have active modifications
you're working on, although it may require a bit of manual juggling.
In short, the process is fairly simple - get up-to-date
spotless.gradle on to your branch (from master), then reformat the
code on your branch and commit it. git should be smart enough to
figure out the differences between your branch and master (after
reformatting) - and these differences should be in your modified code
only.
Let me know if you need me to do this directly on any of your branches
and I'll be happy to help.
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Code reformatting
Posted by Dawid Weiss <da...@gmail.com>.
I added some instructions on how to help out here:
https://issues.apache.org/jira/browse/LUCENE-9570
spotless.gradle has a long list of projects that need to be reviewed.
You can pick a small one and take it from there.
Dawid
On Wed, Dec 23, 2020 at 8:07 AM Dawid Weiss <da...@gmail.com> wrote:
>
> It is currently limited to a subset of the code - reformatted the code
> that's already formatted, so a no-ip. See exclusions in
> spotless.gradle. You need to add the module there and then perhaps
> limit to a single package so that the diff is not too overwhelming.
>
>
> On Tue, Dec 22, 2020 at 11:58 PM David Smiley <ds...@apache.org> wrote:
> >
> > I tried to use this on master for a particular module lucene/spatial-extras to see what happens. I ran "gw tidy" and it ran the tasks but did nothing discernable. Any clues what to do?
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Tue, Dec 22, 2020 at 1:58 PM Dawid Weiss <da...@gmail.com> wrote:
> >>
> >> Yeah - those single-line comments that were broken are mostly because
> >> they were just too long to fit in a single line. Other blocks (with
> >> shorter single-line
> >> comments) were just fine.
> >>
> >> I've seen a couple other oddities resulting from //-type comments
> >> inside statements
> >> or right after variable declarations. These are wrapped in an
> >> unintuitive way too.
> >> I moved a few (so that they appeared before the variable) but
> >> otherwise didn't want
> >> to change too much. Like I said - these things can be corrected/ moved
> >> later on (and reformatted).
> >>
> >> > it's not always easy to coordinate sweeping changes while others continue to mess around!
> >>
> >> True. That's why I wanted to have it done fairly quickly so that we
> >> can just move on. I'll finish
> >> one or two modules myself to get the corner cases right and then I'll
> >> probably ask for help.
> >> Viewing the diff a package-at-a-time takes fairly little effort (5-10
> >> minutes) and it'd help enormously
> >> if we could somehow parallelise this effort over multiple people. I'll
> >> let you all know when I think
> >> it's ready; a day or two should be enough for me.
> >>
> >> Dawid
> >>
> >> On Tue, Dec 22, 2020 at 7:12 PM Michael Sokolov <ms...@gmail.com> wrote:
> >> >
> >> > Yes, that is what I saw; line breaking choices that are different than
> >> > what I would manually have chosen. I don't mean to sound negative -
> >> > this is a nice improvement that gets us away from having to fuss about
> >> > indentation and other formatting. Even regarding these line breaks, it
> >> > is sensible to have the control to insist that single-line comments
> >> > are not merged where block comments are merged and reflowed, so we'll
> >> > learn to adapt to its rules and get things looking the way we want.
> >> > Thanks, Dawid for pushing ahead with this, it's not always easy to
> >> > coordinate sweeping changes while others continue to mess around!
> >> >
> >> > -Mike
> >> >
> >> > On Tue, Dec 22, 2020 at 12:49 PM Dawid Weiss <da...@gmail.com> wrote:
> >> > >
> >> > > > I see it there - yes, it makes some occasional widows, and sometimes
> >> > > > fails to join up consecutive single-line comments (I think you
> >> > > > mentioned this elsewhere) but I can live with it :)
> >> > >
> >> > > I review those diffs manually (for now at least). Some things are indeed
> >> > > more verbose but I think they can be lived with (or corrected manually
> >> > > at a later time).
> >> > >
> >> > > Single-line comments leave (typographical) widows when a long
> >> > > single-line comment is broken because it exceeds line length.
> >> > > To me the formatter intentionally doesn't treat consecutive
> >> > > single-line comments as a block; it breaks long single-lines but
> >> > > doesn't reflow them. So:
> >> > >
> >> > > // really really long comment on a single line
> >> > > // that looks like this
> >> > >
> >> > > could be broken into:
> >> > >
> >> > > // really really long comment on a single
> >> > > // line
> >> > > // that looks like this
> >> > >
> >> > > I've seen examples when a reflow would actually corrupt the content of
> >> > > the message so I guess no solution is ideal. If it's a block comment
> >> > > then it should be a /* */ - then (again, I think) the content
> >> > > undergoes a reflow.
> >> > >
> >> > > All this said, I think overall it's doing a great job, especially with
> >> > > inconsistencies around operators, indents, javadoc etc. Sometimes it
> >> > > tends to be verbose with method calls that have an insane number of
> >> > > parameters (lining up over multiple lines). I've grown used to it -
> >> > > it's really something you just live with after a while. And when it's
> >> > > particularly bothersome, I just reformat the code somehow to have
> >> > > fewer arguments, break long arithmetics into smaller local variables,
> >> > > etc. This can be done gradually at a later time.
> >> > >
> >> > > So far I am pretty happy with what I've seen in those diffs though.
> >> > >
> >> > > 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: Code reformatting
Posted by Dawid Weiss <da...@gmail.com>.
It is currently limited to a subset of the code - reformatted the code
that's already formatted, so a no-ip. See exclusions in
spotless.gradle. You need to add the module there and then perhaps
limit to a single package so that the diff is not too overwhelming.
On Tue, Dec 22, 2020 at 11:58 PM David Smiley <ds...@apache.org> wrote:
>
> I tried to use this on master for a particular module lucene/spatial-extras to see what happens. I ran "gw tidy" and it ran the tasks but did nothing discernable. Any clues what to do?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Dec 22, 2020 at 1:58 PM Dawid Weiss <da...@gmail.com> wrote:
>>
>> Yeah - those single-line comments that were broken are mostly because
>> they were just too long to fit in a single line. Other blocks (with
>> shorter single-line
>> comments) were just fine.
>>
>> I've seen a couple other oddities resulting from //-type comments
>> inside statements
>> or right after variable declarations. These are wrapped in an
>> unintuitive way too.
>> I moved a few (so that they appeared before the variable) but
>> otherwise didn't want
>> to change too much. Like I said - these things can be corrected/ moved
>> later on (and reformatted).
>>
>> > it's not always easy to coordinate sweeping changes while others continue to mess around!
>>
>> True. That's why I wanted to have it done fairly quickly so that we
>> can just move on. I'll finish
>> one or two modules myself to get the corner cases right and then I'll
>> probably ask for help.
>> Viewing the diff a package-at-a-time takes fairly little effort (5-10
>> minutes) and it'd help enormously
>> if we could somehow parallelise this effort over multiple people. I'll
>> let you all know when I think
>> it's ready; a day or two should be enough for me.
>>
>> Dawid
>>
>> On Tue, Dec 22, 2020 at 7:12 PM Michael Sokolov <ms...@gmail.com> wrote:
>> >
>> > Yes, that is what I saw; line breaking choices that are different than
>> > what I would manually have chosen. I don't mean to sound negative -
>> > this is a nice improvement that gets us away from having to fuss about
>> > indentation and other formatting. Even regarding these line breaks, it
>> > is sensible to have the control to insist that single-line comments
>> > are not merged where block comments are merged and reflowed, so we'll
>> > learn to adapt to its rules and get things looking the way we want.
>> > Thanks, Dawid for pushing ahead with this, it's not always easy to
>> > coordinate sweeping changes while others continue to mess around!
>> >
>> > -Mike
>> >
>> > On Tue, Dec 22, 2020 at 12:49 PM Dawid Weiss <da...@gmail.com> wrote:
>> > >
>> > > > I see it there - yes, it makes some occasional widows, and sometimes
>> > > > fails to join up consecutive single-line comments (I think you
>> > > > mentioned this elsewhere) but I can live with it :)
>> > >
>> > > I review those diffs manually (for now at least). Some things are indeed
>> > > more verbose but I think they can be lived with (or corrected manually
>> > > at a later time).
>> > >
>> > > Single-line comments leave (typographical) widows when a long
>> > > single-line comment is broken because it exceeds line length.
>> > > To me the formatter intentionally doesn't treat consecutive
>> > > single-line comments as a block; it breaks long single-lines but
>> > > doesn't reflow them. So:
>> > >
>> > > // really really long comment on a single line
>> > > // that looks like this
>> > >
>> > > could be broken into:
>> > >
>> > > // really really long comment on a single
>> > > // line
>> > > // that looks like this
>> > >
>> > > I've seen examples when a reflow would actually corrupt the content of
>> > > the message so I guess no solution is ideal. If it's a block comment
>> > > then it should be a /* */ - then (again, I think) the content
>> > > undergoes a reflow.
>> > >
>> > > All this said, I think overall it's doing a great job, especially with
>> > > inconsistencies around operators, indents, javadoc etc. Sometimes it
>> > > tends to be verbose with method calls that have an insane number of
>> > > parameters (lining up over multiple lines). I've grown used to it -
>> > > it's really something you just live with after a while. And when it's
>> > > particularly bothersome, I just reformat the code somehow to have
>> > > fewer arguments, break long arithmetics into smaller local variables,
>> > > etc. This can be done gradually at a later time.
>> > >
>> > > So far I am pretty happy with what I've seen in those diffs though.
>> > >
>> > > 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: Code reformatting
Posted by David Smiley <ds...@apache.org>.
I tried to use this on master for a particular module lucene/spatial-extras
to see what happens. I ran "gw tidy" and it ran the tasks but did nothing
discernable. Any clues what to do?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Dec 22, 2020 at 1:58 PM Dawid Weiss <da...@gmail.com> wrote:
> Yeah - those single-line comments that were broken are mostly because
> they were just too long to fit in a single line. Other blocks (with
> shorter single-line
> comments) were just fine.
>
> I've seen a couple other oddities resulting from //-type comments
> inside statements
> or right after variable declarations. These are wrapped in an
> unintuitive way too.
> I moved a few (so that they appeared before the variable) but
> otherwise didn't want
> to change too much. Like I said - these things can be corrected/ moved
> later on (and reformatted).
>
> > it's not always easy to coordinate sweeping changes while others
> continue to mess around!
>
> True. That's why I wanted to have it done fairly quickly so that we
> can just move on. I'll finish
> one or two modules myself to get the corner cases right and then I'll
> probably ask for help.
> Viewing the diff a package-at-a-time takes fairly little effort (5-10
> minutes) and it'd help enormously
> if we could somehow parallelise this effort over multiple people. I'll
> let you all know when I think
> it's ready; a day or two should be enough for me.
>
> Dawid
>
> On Tue, Dec 22, 2020 at 7:12 PM Michael Sokolov <ms...@gmail.com>
> wrote:
> >
> > Yes, that is what I saw; line breaking choices that are different than
> > what I would manually have chosen. I don't mean to sound negative -
> > this is a nice improvement that gets us away from having to fuss about
> > indentation and other formatting. Even regarding these line breaks, it
> > is sensible to have the control to insist that single-line comments
> > are not merged where block comments are merged and reflowed, so we'll
> > learn to adapt to its rules and get things looking the way we want.
> > Thanks, Dawid for pushing ahead with this, it's not always easy to
> > coordinate sweeping changes while others continue to mess around!
> >
> > -Mike
> >
> > On Tue, Dec 22, 2020 at 12:49 PM Dawid Weiss <da...@gmail.com>
> wrote:
> > >
> > > > I see it there - yes, it makes some occasional widows, and sometimes
> > > > fails to join up consecutive single-line comments (I think you
> > > > mentioned this elsewhere) but I can live with it :)
> > >
> > > I review those diffs manually (for now at least). Some things are
> indeed
> > > more verbose but I think they can be lived with (or corrected manually
> > > at a later time).
> > >
> > > Single-line comments leave (typographical) widows when a long
> > > single-line comment is broken because it exceeds line length.
> > > To me the formatter intentionally doesn't treat consecutive
> > > single-line comments as a block; it breaks long single-lines but
> > > doesn't reflow them. So:
> > >
> > > // really really long comment on a single line
> > > // that looks like this
> > >
> > > could be broken into:
> > >
> > > // really really long comment on a single
> > > // line
> > > // that looks like this
> > >
> > > I've seen examples when a reflow would actually corrupt the content of
> > > the message so I guess no solution is ideal. If it's a block comment
> > > then it should be a /* */ - then (again, I think) the content
> > > undergoes a reflow.
> > >
> > > All this said, I think overall it's doing a great job, especially with
> > > inconsistencies around operators, indents, javadoc etc. Sometimes it
> > > tends to be verbose with method calls that have an insane number of
> > > parameters (lining up over multiple lines). I've grown used to it -
> > > it's really something you just live with after a while. And when it's
> > > particularly bothersome, I just reformat the code somehow to have
> > > fewer arguments, break long arithmetics into smaller local variables,
> > > etc. This can be done gradually at a later time.
> > >
> > > So far I am pretty happy with what I've seen in those diffs though.
> > >
> > > Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Code reformatting
Posted by Dawid Weiss <da...@gmail.com>.
Yeah - those single-line comments that were broken are mostly because
they were just too long to fit in a single line. Other blocks (with
shorter single-line
comments) were just fine.
I've seen a couple other oddities resulting from //-type comments
inside statements
or right after variable declarations. These are wrapped in an
unintuitive way too.
I moved a few (so that they appeared before the variable) but
otherwise didn't want
to change too much. Like I said - these things can be corrected/ moved
later on (and reformatted).
> it's not always easy to coordinate sweeping changes while others continue to mess around!
True. That's why I wanted to have it done fairly quickly so that we
can just move on. I'll finish
one or two modules myself to get the corner cases right and then I'll
probably ask for help.
Viewing the diff a package-at-a-time takes fairly little effort (5-10
minutes) and it'd help enormously
if we could somehow parallelise this effort over multiple people. I'll
let you all know when I think
it's ready; a day or two should be enough for me.
Dawid
On Tue, Dec 22, 2020 at 7:12 PM Michael Sokolov <ms...@gmail.com> wrote:
>
> Yes, that is what I saw; line breaking choices that are different than
> what I would manually have chosen. I don't mean to sound negative -
> this is a nice improvement that gets us away from having to fuss about
> indentation and other formatting. Even regarding these line breaks, it
> is sensible to have the control to insist that single-line comments
> are not merged where block comments are merged and reflowed, so we'll
> learn to adapt to its rules and get things looking the way we want.
> Thanks, Dawid for pushing ahead with this, it's not always easy to
> coordinate sweeping changes while others continue to mess around!
>
> -Mike
>
> On Tue, Dec 22, 2020 at 12:49 PM Dawid Weiss <da...@gmail.com> wrote:
> >
> > > I see it there - yes, it makes some occasional widows, and sometimes
> > > fails to join up consecutive single-line comments (I think you
> > > mentioned this elsewhere) but I can live with it :)
> >
> > I review those diffs manually (for now at least). Some things are indeed
> > more verbose but I think they can be lived with (or corrected manually
> > at a later time).
> >
> > Single-line comments leave (typographical) widows when a long
> > single-line comment is broken because it exceeds line length.
> > To me the formatter intentionally doesn't treat consecutive
> > single-line comments as a block; it breaks long single-lines but
> > doesn't reflow them. So:
> >
> > // really really long comment on a single line
> > // that looks like this
> >
> > could be broken into:
> >
> > // really really long comment on a single
> > // line
> > // that looks like this
> >
> > I've seen examples when a reflow would actually corrupt the content of
> > the message so I guess no solution is ideal. If it's a block comment
> > then it should be a /* */ - then (again, I think) the content
> > undergoes a reflow.
> >
> > All this said, I think overall it's doing a great job, especially with
> > inconsistencies around operators, indents, javadoc etc. Sometimes it
> > tends to be verbose with method calls that have an insane number of
> > parameters (lining up over multiple lines). I've grown used to it -
> > it's really something you just live with after a while. And when it's
> > particularly bothersome, I just reformat the code somehow to have
> > fewer arguments, break long arithmetics into smaller local variables,
> > etc. This can be done gradually at a later time.
> >
> > So far I am pretty happy with what I've seen in those diffs though.
> >
> > Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Code reformatting
Posted by Michael Sokolov <ms...@gmail.com>.
Yes, that is what I saw; line breaking choices that are different than
what I would manually have chosen. I don't mean to sound negative -
this is a nice improvement that gets us away from having to fuss about
indentation and other formatting. Even regarding these line breaks, it
is sensible to have the control to insist that single-line comments
are not merged where block comments are merged and reflowed, so we'll
learn to adapt to its rules and get things looking the way we want.
Thanks, Dawid for pushing ahead with this, it's not always easy to
coordinate sweeping changes while others continue to mess around!
-Mike
On Tue, Dec 22, 2020 at 12:49 PM Dawid Weiss <da...@gmail.com> wrote:
>
> > I see it there - yes, it makes some occasional widows, and sometimes
> > fails to join up consecutive single-line comments (I think you
> > mentioned this elsewhere) but I can live with it :)
>
> I review those diffs manually (for now at least). Some things are indeed
> more verbose but I think they can be lived with (or corrected manually
> at a later time).
>
> Single-line comments leave (typographical) widows when a long
> single-line comment is broken because it exceeds line length.
> To me the formatter intentionally doesn't treat consecutive
> single-line comments as a block; it breaks long single-lines but
> doesn't reflow them. So:
>
> // really really long comment on a single line
> // that looks like this
>
> could be broken into:
>
> // really really long comment on a single
> // line
> // that looks like this
>
> I've seen examples when a reflow would actually corrupt the content of
> the message so I guess no solution is ideal. If it's a block comment
> then it should be a /* */ - then (again, I think) the content
> undergoes a reflow.
>
> All this said, I think overall it's doing a great job, especially with
> inconsistencies around operators, indents, javadoc etc. Sometimes it
> tends to be verbose with method calls that have an insane number of
> parameters (lining up over multiple lines). I've grown used to it -
> it's really something you just live with after a while. And when it's
> particularly bothersome, I just reformat the code somehow to have
> fewer arguments, break long arithmetics into smaller local variables,
> etc. This can be done gradually at a later time.
>
> So far I am pretty happy with what I've seen in those diffs though.
>
> Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Code reformatting
Posted by Dawid Weiss <da...@gmail.com>.
> I see it there - yes, it makes some occasional widows, and sometimes
> fails to join up consecutive single-line comments (I think you
> mentioned this elsewhere) but I can live with it :)
I review those diffs manually (for now at least). Some things are indeed
more verbose but I think they can be lived with (or corrected manually
at a later time).
Single-line comments leave (typographical) widows when a long
single-line comment is broken because it exceeds line length.
To me the formatter intentionally doesn't treat consecutive
single-line comments as a block; it breaks long single-lines but
doesn't reflow them. So:
// really really long comment on a single line
// that looks like this
could be broken into:
// really really long comment on a single
// line
// that looks like this
I've seen examples when a reflow would actually corrupt the content of
the message so I guess no solution is ideal. If it's a block comment
then it should be a /* */ - then (again, I think) the content
undergoes a reflow.
All this said, I think overall it's doing a great job, especially with
inconsistencies around operators, indents, javadoc etc. Sometimes it
tends to be verbose with method calls that have an insane number of
parameters (lining up over multiple lines). I've grown used to it -
it's really something you just live with after a while. And when it's
particularly bothersome, I just reformat the code somehow to have
fewer arguments, break long arithmetics into smaller local variables,
etc. This can be done gradually at a later time.
So far I am pretty happy with what I've seen in those diffs though.
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Code reformatting
Posted by Dawid Weiss <da...@gmail.com>.
> It is fine, if there are conflicts and will juggle them :)
If you try to merge directly, there will be conflicts. But if you do
what I describe below, it
should require no manual assistance and will ease the pain to
literally zero effort.
// get the latest changes (I assume origin points at apache or github).
git fetch origin
// get your branch. I assume it compiles.
git checkout my-branch
// get the latest spotless scripts from master and apply it locally
git checkout master -- gradle
// reformat code on my-branch
./gradlew tidy
git commit -am "Just applying the formatter"
// now diff against the (reformatted) master - you should only see your local
// changes; the code is formatted identically on both branches.
git diff origin/master
// and merge if you like.
git merge origin/master
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Code reformatting
Posted by Ignacio Vera <iv...@gmail.com>.
Hi Dawid,
It is fine, if there are conflicts and will juggle them :)
thanks for this effort, it is very cool!
On Tue, Dec 22, 2020 at 5:04 PM Michael Sokolov <ms...@gmail.com> wrote:
> I see it there - yes, it makes some occasional widows, and sometimes
> fails to join up consecutive single-line comments (I think you
> mentioned this elsewhere) but I can live with it :)
>
> On Tue, Dec 22, 2020 at 10:07 AM Dawid Weiss <da...@gmail.com>
> wrote:
> >
> > > Looks as if javadoc is likely to be the main challenge?
> >
> > Not really - it's all handled fairly well (automatically). I merged your
> > changes to master branch and reformatted it locally, I'll merge back to
> master
> > soon.
> >
> > Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Code reformatting
Posted by Michael Sokolov <ms...@gmail.com>.
I see it there - yes, it makes some occasional widows, and sometimes
fails to join up consecutive single-line comments (I think you
mentioned this elsewhere) but I can live with it :)
On Tue, Dec 22, 2020 at 10:07 AM Dawid Weiss <da...@gmail.com> wrote:
>
> > Looks as if javadoc is likely to be the main challenge?
>
> Not really - it's all handled fairly well (automatically). I merged your
> changes to master branch and reformatted it locally, I'll merge back to master
> soon.
>
> Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Code reformatting
Posted by Dawid Weiss <da...@gmail.com>.
> Looks as if javadoc is likely to be the main challenge?
Not really - it's all handled fairly well (automatically). I merged your
changes to master branch and reformatted it locally, I'll merge back to master
soon.
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Code reformatting
Posted by Michael Sokolov <ms...@gmail.com>.
Hmm, I committed my outstanding PR with no conflicts, so I assume you
didn't get the reformatting in yet; let me know if *I* can help :)
-MIke
On Tue, Dec 22, 2020 at 9:06 AM Michael Sokolov <ms...@gmail.com> wrote:
>
> Thanks for the heads up. If you commit your changes first, I'll tackle the reformatting and let you know if I run into issues. Looks as if javadoc is likely to be the main challenge?
>
> On Tue, Dec 22, 2020, 8:56 AM Dawid Weiss <da...@gmail.com> wrote:
>>
>> Hi Mike, Ignacio,
>>
>> Just wanted to let you know that I wanted to go through the rest of
>> lucene-core reformatting soon-ish (I've done a lot on the branch
>> already and a subset of packages ended on master too).
>>
>> This will touch packages which you've been working on recently. I
>> don't think it'll be a problem, even if you have active modifications
>> you're working on, although it may require a bit of manual juggling.
>>
>> In short, the process is fairly simple - get up-to-date
>> spotless.gradle on to your branch (from master), then reformat the
>> code on your branch and commit it. git should be smart enough to
>> figure out the differences between your branch and master (after
>> reformatting) - and these differences should be in your modified code
>> only.
>>
>> Let me know if you need me to do this directly on any of your branches
>> and I'll be happy to help.
>>
>> Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Code reformatting
Posted by Michael Sokolov <ms...@gmail.com>.
Thanks for the heads up. If you commit your changes first, I'll tackle the
reformatting and let you know if I run into issues. Looks as if javadoc is
likely to be the main challenge?
On Tue, Dec 22, 2020, 8:56 AM Dawid Weiss <da...@gmail.com> wrote:
> Hi Mike, Ignacio,
>
> Just wanted to let you know that I wanted to go through the rest of
> lucene-core reformatting soon-ish (I've done a lot on the branch
> already and a subset of packages ended on master too).
>
> This will touch packages which you've been working on recently. I
> don't think it'll be a problem, even if you have active modifications
> you're working on, although it may require a bit of manual juggling.
>
> In short, the process is fairly simple - get up-to-date
> spotless.gradle on to your branch (from master), then reformat the
> code on your branch and commit it. git should be smart enough to
> figure out the differences between your branch and master (after
> reformatting) - and these differences should be in your modified code
> only.
>
> Let me know if you need me to do this directly on any of your branches
> and I'll be happy to help.
>
> Dawid
>