So, one advantage of merge commits is that review of each branch is potentially easier, as the merge commit helps direct the reviewer’s attention. However, in my experience most of the focus during review is to the main branch anyway. Having separate tickets to track backports, and permitting them to occur out of band, could improve the quality of review. We can also likely synthesise the merge commits for the purpose of review using something like
git checkout patch-4.0~1 git checkout -b patch-4.0-review git merge -s ours patch-4.1~1 git merge --no-commit patch-4.1 git checkout patch-4.0 . git commit From: bened...@apache.org <bened...@apache.org> Date: Wednesday, 5 January 2022 at 21:07 To: Mick Semb Wever <m...@apache.org> Cc: dev <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Releasable trunk and quality > If you see a merge commit in the history, isn't it normal to presume that it > will contain the additional change for that branch for the parent commit > getting merged in? Sure, but it is exceptionally non-trivial to treat the work as a single diff in any standard UX. In practice it becomes 3 or 4 diffs, none of which tell the whole story (and all of which bleed legacy details of earlier branches). This is a genuine significant pain point when doing archaeology, something I and others do quite frequently, and a large part of why I want to see them gone. > Folk forget to pull, rebase, then go to push and realise one of their patches > on a branch needs rebasing and rework. That rework may make them reconsider > the patch going to the other branches too. Conversely, this is exceptionally painful when maintaining branches and forks, and I can attest to the pain of maintaining these branches so they may be committed atomically to having wasted literal person-weeks in my time on the project. I do not recall experiencing a significant benefit in return. > do i have to start text searching the git history Yes. This is so simple as to be a non-issue - surely you must search git log semi-regularly? It is a frequent part of the job of developing against the project in my experience. > Developing patch on hardest branch first, then working on each softer branch. > I don't know how important this is, but I have found it a useful practice > that encourages smaller, more precise patches overall. I don’t think this strategy determines which branch is first developed against. However, if it did, it would seem to me to be a clear mark against the current system, which incentivises fully developing against the oldest version before forward-porting its entirety. Developing primarily against the most recent branch incentivises back-porting more minimal versions of the work, once the scope of the work is fully understood.
