I haven't done a bit piece of work in the ASF code repo since the migration to git; though I have done it in the svn era.
Currently with private git repos -anyone gets SCM control of their source -you can commit for your own reasons (about to make a change, want a private jenkins run, ...) and gain from having many small checkins. More succinctly: if you aren't checking in your work 2+ times a day —why not? -rebasing a painful necessity on personal, private branches to keep the final patch to hadoop git a single diff With the private git process that's the defacto standard, we lose history anyway. I know what I've done and somewhere there's a tag in my own github repo of my work to create a JIRA. But we don't always need that entire history of "trying to debug kerberos", "typo in exception", and other stuff that accrues during the work. I think therefore that I'm in favour of big squash commits. What we could do is extend that with a policy of 1. tag the final commit used to make the patch, something like tag_HADOOP-8192. The tag ensures that the history isn't gc'd 2. Delete the branch (keeps the #of branches down) 3. In the JIRA, include the name of the tag and the git commit number in the comments. Someone curious can rebuild that history
