> 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.
