> > 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?
I've been noodling on this a bit; I think it's a question of degree. When I see a merge commit my intuitive expectation is "it takes the context of application of diff over there and moves it over here", not "it claims to have taken the context from over there but actually only takes it symbolically (-s ours), and all the changes are manually applied by a separate motion here". Applying hand-crafted patches to each branch w/out "merge -s ours" is more _honest_ in the case where we can't merge between branches. I think the status quo is largely fine if you have a trivial change and a merge commit between branches, but I also find trivial patch application uninteresting and simple enough that either merge strategy is fine. All this said, I am *definitively* not advocating we have different merge strategies based on the size of a patch and whether it necessitates the -s ours, more trying to explore the nuance behind my reaction to the status quo. On Thu, Jan 6, 2022 at 7:28 AM bened...@apache.org <bened...@apache.org> wrote: > 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. > > > > > > >
