On Thu, 29 Oct 2009, Øyvind Harboe wrote: > Maybe I'm using rebase incorrectly, but when code is reordered > (to avoid declarations to resolve forward references), then a > rebase will not run without requiring manual merging.
Exact. > If rebase can't merge reordering of code automatically, then I > would generally like such pervasive refactoring of code to take place > at an announced time... Makes branches easier to maintain... Indeed. This is why people making those kind of massive code reordering should usually publish their branches early and let people know about them, and come to an agreement with the rest of the developers for merging those branches first during the next development cycle. Zach mentioned about having over 50 cleanup patches waiting in a branch which would certainly fit that bill as well. This way, you can start making your own feature branches apply on top of those cleanup branches in order to reduce the magnitude of manual conflict resolution required when it will be time to merge your own branch in. > diff is also similarly "broken". I haven't found an "ignore > reordered lines" a la -w == ignore whitespace changes. The git rebase feature is using diff underneath. > Any tips on how to better cope w/reordered code in merges > w/git? So far the best solution is social coordination and communication. > More generally: does anyone have a great reference to > git branches, rebase & automatically refactored java code? > > (This would include name changes of classes, extracting methods, > rename of files, etc.) If you really want to strive into academic topics, you may try to implement some of the fanciest merge algorithms. Git let you plug any external merge algorithm you want if you come up with a better one than the default (which is a standard 3-way merge) for domain specific files. For example, someone once came up with a script to invoke M$ Word's ability to merge changes from two .doc files together. Nicolas
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
