I prefer Proposal #1 as well. Squashing some of the commits seems a major improvement over our previous model of a single commit for the entire branch.
On Tue, Aug 11, 2015 at 2:19 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > Hi all, > > We are currently working on a pretty substantial new feature in a branch > over at HDFS-7285. As the # of commits has grown, running `git rebase` and > fixing conflicts in the 180+ commits has become untenable. As you may > recall, we voted to use a rebase workflow when we did the switch from SVN > to git a year ago [1]. > > I'm aware of two proposals right now: > > ======== > > Proposal 1: Squash some of the commits to make rebase easier. > > Often times, intermediate commits are made to code that get changed again > later, and thus don't end up in HEAD. Fixing conflicts in these > intermediate commits is a waste of time, especially with 180 commits. I run > into this issue even with my local feature branches, and thus squash. > > The downside is that squashing loses some of the development history, since > now multiple JIRAs are combined into a single commit. There are some ways > to mitigate this: the old branch with the full history can be left in > place, and the squashed commits can reference the JIRAs that have been > squashed together. > > ======== > > Proposal 2: Allow merge-based workflows too. > > This is what we were doing in the SVN days. Periodically merge trunk to the > branch, resulting in merge commits to resolve conflicts. When the branch is > ready, merge it back to trunk. > > I read through the discussion thread [2] where we decided to go with > rebase, The concerns were that merge commits pollute history, which was an > issue for HBase and I believe Spark. Merge commits are not associated with > a single JIRA or commit, and fixes are sometimes hidden in merge commits. > This makes backports harder. > > Merge-based workflows also squash the history when backporting to a branch. > In the SVN merge-based days, backporting to branch-2 was typically done as > a single squashed commit. With a rebase workflow, it's possible to rebase > the branch against branch-2 and get the same history as trunk. > > ======== > > My mild preference is for Proposal #1 since it results in a clean linear > history in both trunk and branch-2, but it has to be understood that > squashing is sometimes a required part of a rebase workflow. If the core > issue with squashing is maintaining development history, I think it's > satisfied by keeping old branches around and referencing the squashed > JIRAs. > > Welcome other thoughts here too. > > Best, > Andrew > > [1]: > > http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201408.mbox/%3CCALwhT94Y64M9keY25Ry_QOLUSZQT29tJQ95twsoa8xXrcNTxpQ%40mail.gmail.com%3E > > [2]: > > http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201408.mbox/%3CCALwhT97bM36X6-3%3DcCUwaAKxZ80jfZwuf53BTR7TbWwV5e%2BXkA%40mail.gmail.com%3E >
