> - hides changes inside the merge commit >
This is what all merge commits do. 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? > - is exposed to race w/other committers across multiple branches requiring > --atomic > This is a positive, IMHO. 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. > +(?) Is the devil we know > + Bi-directional relationship between patches showing which branches it was applied to (and how). From the original commit or any of the merge commits I can see which branches, and where the original commit, was applied. (See the mongo example from Henrik, how do I see which other branches the trunk commit was committed to? do i have to start text searching the git history or going through the ticket system :-( + 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. Agree we want a defined end goal. And all for experimenting and testing simpler/cleaner approaches. >
