| Re: [mylyn-reviews-dev] git best practices |
when I have a series of commits and rebase them, each and every commit gets individually reapplied. But I will only check the latest one for correctness and consistency (although I could of course go through all commits, get them to my working tree, build and test them). This could lead to commits that would not even compile. Or if I have a commit introducing a null guard – and on the central git repository somebody removed the possible null condition, after a rebase it looks like I have introduced a null guard where null could never happen. Jan From: mylyn-reviews-dev-bounces@xxxxxxxxxxx [mailto:mylyn-reviews-dev-bounces@xxxxxxxxxxx] On Behalf Of Matthias Sohn 2011/2/7 Lohre, Jan <jan.lohre@xxxxxxx> I would also prefer a flat history (i.e. using 'rebase' in favor of 'merge'). However we also should have small "do one thing" commits and 'rebase' with a series of commits has major drawbacks. (commits can get inconsistent) Could you give an example for these rebase drawback you see, we use rebase frequently also on patch series, so I would be interested to learn where you think it doesn't work as you expected. -- Matthias |