I'm not against adding in jalopy to to make the merger's happen easier, and for future mergers to be easier as well. I just wanted to bring up that there was opposition and it should be taken into consideration.
Brent Owens (The Open Planning Project) Andrea Aime wrote: > Brent Owens ha scritto: >> I thought this was already discussed and voted down? > > Hum, if you refer to > http://www.nabble.com/Code-Formatting---Vote-t1278276.html#a3414679 > it seems to me most of the people was in favour, with a strong opposition > from David (based on the fact that it makes branch mergin harder, while I > assert exactly the opposite, read later). > >> Actual changes before this event will be lost in the formatting >> changes, and that was the main reason for no auto-formatting. > > What? No, exactly the opposite. > On the trunk, every change before auto-formatting is dutifully stored > in the version control, is not lost. > Have you tried doing a diff between branches and trunk? I did: most of > the changes you see in the diffs are formatting related, you won't see > the real changes at all. > > But if you reformat both before diffing, you'll see the actual changes. > If we merge now, we'll get both the real changes and the code style ones, > without possibility to say which is which. > > Think also about normal commits in the context of the trunk. Programmer A > modifies code, and commits (say A uses spaces for indenting). > Programmer B opens the file to do a fix and it's all ruined in its > editor, > because he uses tabs for indenting. He fixes both formatting and the bug. > Commits. The bug fix will be hidden in the changelog, because of > formatting > changes. > >> That and it will never please everyone: we all have our own styles. > > We also are a team, and we should work as one. How many modules are owned > by a single developer? > If everybody does its own we just end up with a mess. > I like formatting with 2 spaces indent and 100 columns, or 4 spaces > indent > and 130 columns. Does this mean I can freely reformat every file where > I do > some significant change (not one liners) only because "I have my own > style"? > > On the other side, if there is an automated formatting tool in the build, > (and since every serious developer does a build before committing), > the code > will always be formatted the same way and only actual changes will > show up > in the svn logs. > >> Would it be an option to format locally and then merge? Without >> inflicting formatting on everyone? > > Would that change anything? Once you commit after your local merge you'll > commit both actual code changes mixed in a ton of formatting changes. > >> aside: I know that an 80 column width will make a lot of people cry. >> 80 columns is old school and cruel, especially with geotool's long >> method and class names. > > I hear you, yet if we start discussing about exceptions to the sun > coding convention we'll never end up. As you said, when it comes to > tastes > everybody has its own style. > That's why where I work nobody is allowed to have its own, a coding > standard > is decided up front and personal variations aren't allowed. We spend our > time coding, not reformatting code (the IDE does that for us). > > Cheers > Andrea > _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
