"Alan Knight"<knight@acm.org> wrote: > Which parts of this are real changes and which are just because somebody > felt it was important to reformat everything? :-) Reformatting is relatively easy, but it would be really nice if the tooling could identify (at least some) refactoring too. Best I've seen so far is barely identifying simple method renames, I'm fairly confident we could do better than that. On top of that most tools make it difficult to compare bits of code that don't reside in the exact same method. The fact of life is that code moves around as responsibilities get reallocated. A good merge tool should let me compare arbitrary bits of changes with ease. As it is the "art of merging" is primarily being able to pick out slightest differences by simply eyeballing chunks of code yourself. It seems that merge tools assume that the person merging is the one who wrote the change, that is often not the case. It's great that the obvious stuff can be merged automatically nowadays, but any non-trivial merge case requires actual understanding of the change.

If the tool only compares the new proposed version of a method with the current one, then you might miss something because sometimes the new version should be compared against a method with another selector. This is clearly the case when the change renames a selector. It also happens when the change extracts some lines from the body of a larger method. So, to put this in a question (as Stef is requesting) I would add the following: What's the method (or method fragment) that this new method modifies? leandro caniglia ph.d. | chief technologist | *caesar** systems *| *see clearly. decide smarter**.* lcaniglia@caesarsystems.com | t: +1.281.598.8810 +1.281.617.2972 +54.11.4389.0126 | petrovr.blogspot.com | www.caesarsystems.com This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message. On Wed, Nov 23, 2011 at 7:24 PM, <mkobetic@cincom.com> wrote: > "Alan Knight"<knight@acm.org> wrote: > > Which parts of this are real changes and which are just because somebody > > felt it was important to reformat everything? :-) > > Reformatting is relatively easy, but it would be really nice if the > tooling could identify (at least some) refactoring too. Best I've seen so > far is barely identifying simple method renames, I'm fairly confident we > could do better than that. > > On top of that most tools make it difficult to compare bits of code that > don't reside in the exact same method. The fact of life is that code moves > around as responsibilities get reallocated. A good merge tool should let me > compare arbitrary bits of changes with ease. As it is the "art of merging" > is primarily being able to pick out slightest differences by simply > eyeballing chunks of code yourself. It seems that merge tools assume that > the person merging is the one who wrote the change, that is often not the > case. It's great that the obvious stuff can be merged automatically > nowadays, but any non-trivial merge case requires actual understanding of > the change. > > _______________________________________________ > Esug-list mailing list > Esug-list@lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >