Understood, and agreed on the need to preserve the commit history. The only reason I thought I'd comment is that the current proposal explicitly mentions "git merge --no-ff" when merging the branch to trunk. "--squash" cannot be combined with "--no-ff", thus I wanted some clarification.
On Fri, Aug 21, 2015 at 3:40 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > > > > I know this is a different topic than the main reason for this vote, but > > has there been a discussion of using a squashed merge as opposed to a > > normal merge when feature branches merge to trunk? Squash merges have > some > > advantages including complicating the branch tree. > > > > Since this [VOTE] explicitly allows a rebase+squash workflow, you can do > this by first squashing the branch with rebase then merging it. We > discussed a lot about the importance of preserving history though, which is > the point of using merge and also carefully annotating squashed commits > when rebasing. This would apply to merge --squash too. > > Ultimately my goal though is to leave it to the contributors to decide. The > dev workflow and integration plan should all be discussed publicly, so we > can figure out what works best in each situation. > > Best, > Andrew >
