On Mon, Jun 2, 2008 at 5:51 PM, Lea Wiemann <lewiemann@xxxxxxxxx> wrote: > 2) I should probably also try to squash patches into larger ones. This will > make it easier to make changes in older commits, since I don't have to edit > several commits, and it reduces the probability of merge conflicts. I'm not > sure how much squashing is appropriate though: For example, would it be okay > to squash a fix like "Git.pm: fix documentation of hash_object" into a > larger "Git.pm: add and fix several methods" commit, where I only mention > the documentation-fix in the log message? It would certainly be helpful in > that it reduces the number of conflicts, but it will make the logs coarser. Why not go for the win and do both? Keep your commit strategy as is, and create a branch whenever you want review, say review-02-06 or such and in that branch you squash the commits as appropriate (perhaps StGit can help here). These patches are mostly not intended for inclusion just yet (but for review only), right? Instead of sending all the small commits you send a bigger one, perhaps with a link to where the branch can be found for easy checkout. You can keep the branch for the a record or delete it after the review and go on with the next branch. Cheers, Sverre, who thinks a few RFC patches are in place soon for git-stats too and is glad you are doing the fine-tuning wrt patch submission. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
