Tim are you saying at the end of the process you should only see one commit for a JIRA/change. If that is the case then you may be referring to 1.
On Mon, Nov 2, 2015 at 11:09 AM, Timothy Farkas <[email protected]> wrote: > +1 for 3. After review I think everything should still be squashed into 1 > commit, with some exceptions like preserving attribution (for example when > you rename a file or when multiple authors work on a feature). > > On Mon, Nov 2, 2015 at 11:00 AM, Pramod Immaneni <[email protected]> > wrote: > > > I wanted to find out how folks feel about squashing commits for reviews > on > > pull request. This is not for the initial pull request but only for > > subsequent commits to address the reviews. Here are some options. > > > > 1. Squash everything to a single commit. This is the process we are > > following today. Advantage is there is one commit per JIRA and self > > contained. Easy to cherry-pick if needed. > > 2. Preserve the individual commits for pull request reviews. Advantage is > > you preserve the review history in the pull request, the thoughts and > > discussions that went behind the changes and you see the incremental > > changes in separate commits. Disadvantage is you will have to work with > > multiple commits if you are trying to something with the change like > > re-apply it elsewhere. > > 3. A hybrid of 1. and 2. where you don't let the commits grow large. No > > standard set limit but the contributor and committer work keep it to a > > reasonable amount squashing smaller commits. > > 4. Anything you would like to propose. > > > > I would like to add +1 for option 3. > > > > Thanks > > >
