Yes Pramod I must understood your suggestion. I prefer option 1, with the exception of cases where multiple commits are required to preserve attribution.
Utlimately I think the choice depends on what function you want a branch to serve. If you want the branch to tell the story of how the code was developed then option 2 or 3 is superior. If you want the branch to represent purely functional changes that can be easily ported, then option 1 is superior. I prefer the latter view of a branch. Tim On Mon, Nov 2, 2015 at 11:11 AM, Pramod Immaneni <[email protected]> wrote: > 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 > > > > > >
