+1. Preserving sub-commit history also lets others "git blame" stuff on a per commit basis rather than the whole squashed commit.
On Wed, Feb 19, 2020 at 8:25 AM Sean Busbey <bus...@apache.org> wrote: > So long as the backport PRs are lazy consensus instead of the RTC that > a PR generally implies (and the original branch went through) then > this all reads as in line with my own preferences and what we've > mostly done historically. > > On Wed, Feb 19, 2020 at 10:08 AM Nick Dimiduk <ndimi...@apache.org> wrote: > > > > Hello, > > > > We have had a couple feature branches in flight recently. I would like to > > review our project policy regarding how we account for the merging of > these > > feature branches to master and other release line branches. There has > been > > some discussion on this topic around HBASE-18095, but I want to bring it > to > > light outside of that context. Whatever we decide here, we should write > up > > and include in the book. > > > > By way of process, my preference is that when we merge a feature branch, > we > > retain all of the individual commits (one-to-one with Jira sub-tasks). > > Mechanically this means something like the following: > > (1) squash together all commits that correspond with a single Jira > > sub-task, making the history into one commit for one sub-task. > > (2) rebase the feature branch onto master; > > (3) create a PR from the feature branch into master; > > (4) use the "rebase and merge" option when merging the PR; > > (5) update the fixVersion of the umbrella and all sub-tasks to the > > version of master; > > (6) repeat steps 2-5 for each back-port. > > > > My reason for preferring preservation of sub-commit history is that, in > the > > event of follow-on addendums and sub-task (something we have a habit of > > doing), its easy for release line maintainers to account for which of > those > > follow-ons have been applied to their branches of interest. If the > "squash > > and merge" option is chosen, it becomes much more difficult for a release > > manager (or indeed, curious historians) to identify exactly which Jira > > issues are present in the history. > > > > My reason for preferring PRs for merging feature branches (and > back-ports) > > over a developer pushing manually is that it gives the maintainer an > > opportunity to benefit from the pre-commit robot, and > > back-port-branch-specific discussion to occur in the context of the code > > changes proposed. > > > > There are certainly other ways of going about this. I'm curious what > others > > think of the above. > > > > Thanks, > > Nick >
