harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: Subclipse Diff: Are there any way to ignore whitespace when creating patch using Subclipse in Eclipse
Date Sat, 18 Mar 2006 14:03:14 GMT
On Thu, Mar 16, 2006 at 10:09:12AM -0800, Stefano Mazzocchi wrote:
> Richard Liang wrote:
> >Dears,
> >
> >If you select "Spaces only" as Eclipse "tab policy" and you format the 
> >Harmony source code in Eclipse, when you creating patch for the source 
> >code, Subclipse may regard the source code as total different  with the 
> >source in SVN. Then other developers cannot know what you have changed 
> >to the source code. So are there any way to avoid this confusion? Thanks 
> >a lot.
> 
> If you figured that out, I would be the happiest person alive: I *HATE* 
> tabs with a passion and that is the only part of the eclipse that drives 
> me completely insane.

Silly eclipse users...

...the generic problem here is that "diff" is not a very good tool for
representing changes made to large java codebases. What we need is a tool
that represents the change as something like this:

  From: john@apache
  To: harmony-commits
  Subject: svn revision 12345 - foo/bar foo/baz

  Reformatted code (format http://.../harmony.style):
    foo/bar/x.java
    foo/bar/y.java

  Refactorings:
    move-static: foo/bar/x.java -> foo/bar/y.java:
      public static void doStuff(String x)
      public static void doStuff(String x, String y)

I've pretty much figured out how to do this in theory (refactorings are
syntax tree transformations for which you can write a pattern matching
algorithm (parse tree pattern, not text pattern)), its just something that
takes a man-year or two to implement...

...so in the meantime...

...write these kinds of message manually. When you do a code reformat, say
so in the commit message, don't change anything else. When you do some kind
of refactoring, describe the refactoring in the commmit message. This helps
other people understand what you did (figuring out the refactorings from the
diff in the commit message is rather hard).

When you're submitting a patch, submit two patches. One that is just the
code reformat, and the other that is the "real" patch applied to the
reformatted code. The developer applying your patch can then first apply
the reformat patch, commit, and then commit the "real" patch. All he has
to do for the reformat patch is verify that it is just a reformat, and then
he can actually understand the real patch too.

Make sense?

The final thing to do is for projects to lay down a very rigid coding
standards law (I would like to volunteer tim to put his eclipse settings up
on the wiki, I guess that's currently sort-of our de-facto coding standards
rules) and apply it to all the source in one fell swoop. Then you don't
have to submit those reformatting patches.

cheers!

LSD

Mime
View raw message