No, I think that's exactly what people mean when saying "losing the commit history". With the reformatting you would have to go manually through all past commits until you find the commit which changed a given line before the reformatting.
Cheers, Till On Sun, Feb 26, 2017 at 6:32 PM, Alexander Alexandrov < alexander.s.alexand...@gmail.com> wrote: > Just to clarify - by "losing the commit history" you actually mean "losing > the ability to annotate each line in a file with its last commit", right? > > Or is there some other sense in which something is lost after applying bulk > re-format? > > Cheers, > A. > > On Sat, Feb 25, 2017 at 7:10 AM Henry Saputra <henry.sapu...@gmail.com> > wrote: > > > Just want to clarify what unify code style here. > > > > Is the intention to have IDE and Maven plugins to have the same check > style > > rules? > > > > Or are we talking about having ONE code style for both Java and Scala? > > > > - Henry > > > > On Fri, Feb 24, 2017 at 8:08 AM, Greg Hogan <c...@greghogan.com> wrote: > > > > > I agree wholeheartedly with Ufuk. We cannot reformat the codebase, > cannot > > > pause while flushing the PR queue, and won't find a consensus code > style. > > > > > > I think we can create a baseline code style for new and existing > > > contributors for which reformatting on changed files will be acceptable > > for > > > PR reviews. > > > > > > On Fri, Feb 24, 2017 at 5:01 AM, Dawid Wysakowicz < > > > wysakowicz.da...@gmail.com> wrote: > > > > > > > The problem with code style when it is not enforced is that it will > be > > a > > > > matter of luck to what parts of files / new files will it be applied. > > > When > > > > the code style is not applied to whole file, it is pretty much > useless > > > > anyway. You would need to manually select just the fragments one is > > > > changing. The benefits of having code style and enforcing it I see > are: > > > > - being able to apply autoformatter, which speeds up writing code > > > > - it would make reviewing PRs easier as e.g. there would be line > > length > > > > limit applied etc. which will make line breaking more reader > friendly. > > > > > > > > Though I think if a consensus is not reachable it would be good to > once > > > and > > > > forever decide that we don't want a code style and checkstyle. > > > > > > > > 2017-02-24 10:51 GMT+01:00 Ufuk Celebi <u...@apache.org>: > > > > > > > > > On Fri, Feb 24, 2017 at 10:46 AM, Fabian Hueske <fhue...@gmail.com > > > > > > wrote: > > > > > > I agree with Till that encouraging a code style without enforcing > > it > > > > does > > > > > > not make a lot of sense. > > > > > > If we enforce it, we need to touch all files and PRs. > > > > > > > > > > I think it makes sense for new contributors to have a starting > point > > > > > without enforcing anything (I do agree that we are past the point > to > > > > > reach consensus on a style and enforcement ;-)). > > > > > > > > > > > > > > >
