[Ltrace-devel] Pulling in patches

Zach Welch zwelch at codesourcery.com
Thu Oct 7 16:59:01 UTC 2010


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
zwelch at codesourcery.com
(650) 331-3385 x743



More information about the Ltrace-devel mailing list