On 10/06/2010 11:44 PM, Joe Damato wrote: ... > libdl support: > http://github.com/ice799/ltrace/compare/163765561621a9127cee...0ef227193a5e6edc2003 > I've been using this patchset quite a bit and it seems to be OK. I'd > love it if some one else could take a look and review these changes. I > forgot to create a ChangeLog entry for these, so I'll do that and then > try to merge these in.
I would suggest using git rebase to simplify and clean these patches. Casual inspection reveals that they do not preserve atomicity (one change per patch). I also see possible problems with build consistency: each patch should allow the tree to be built and pass all regression tests. Specifically, there is no good reason to have "clean up" patches in the first series of a new feature. Those later changes should be split up and squashed into the original patches. Likewise, there is code that disappears in one patch, reappears in another, and then gets moved to its final location. This kind of churn should be avoided when possible, particularly as the temporary removal of that code will prevent someone from being able to check the tree after each patch. That will cause problems for users of the 'git bisect' command, which can save a lot of time when determining which changes introduced a bug. Concretely, I love using 'git rebase -i' to do this type of rework. Using that tool, it becomes fairly trivial to split, reorder, and merge a series of pending patches. One can make it look as though the code was written correctly the first time. Moreover, this kind of cleaning usually makes it much easier for reviewers to understand the changes. Finally, rebasing can be used to stack several series of patches into a linear history, rather than trying to merge multiple histories. -- Zach Welch CodeSourcery [email protected] (650) 331-3385 x743 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/ltrace-devel
