Re: Development strategy

["Sverre Rabbelier" <alturin@gmail.com>]

On Mon, Jun 2, 2008 at 5:51 PM, Lea Wiemann <lewiemann@gmail.com> 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.