On 11.08.2014 03:13, John Scipione wrote:
Well the commit dates may not be accurate as I tend to move commits around and rebase them constantly as I go along. Committing more incrementally would have meant a lot more commits because you'd see more revision, probably a lot more. I'd estimate it would produce 3x the commits that way.
Given that many of the changes are relatively simple CCID fixes (strcpy() -> strlcpy(), fixed checks, etc.), I'm a bit surprised to hear that, but be that as it may...
I would prefer to say push all the commits for each .cpp/.h pair separately but I just don't know how to do that. For something like this you just can't review via email all the details are there and it's all split out it's just too much data to fit in an email message. git tools though like cgit or a graphical git tool make it much more manageable. The fact that there's a lot of commits just can't be helped, there's a lot of changes.
By now you should be aware, that several of your fellow developers aren't particularly happy with your flawed commit to total commit count ratio and therefore review your commits more thoroughly than those of others. As you should also know, many developers have a very limited Haiku time these days. Pushing a batch of commits collected over a longer period of time pretty much guarantees that most of them won't have time or motivation to do a review of all of them (I certainly don't).
Compared with clicking through the individual commits in cgit or using some other tool, reviewing the diffs on the commit list has very low overhead. Even if you had produced 150 instead of 50 commits by pushing more frequently, reviewing a dozen commits per day is a lot more manageable than 50 at once.
CU, Ingo
