Marshall Dawson has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37532 )
Change subject: [NOT FOR MERGE] northbridge: Don't use both _ADR and _HID ......................................................................
Patch Set 3:
Good thought. But I hesitate because I'm doing all this commits to be merged because to push a board_status report it seems all commits should be merged, if I got it right. Or maybe if the commits are in Gerrit they can be used to build the same coreboot.rom as myself and the board_status report I report is valid if they come from known commit in Gerrit...
Yes, for the board status to be the most meaningful, it should be in code that's merged. IIRC it's not prevented pushing unmerged, however someone trying to reproduce it won't appreciate what you did. There's no good way to communicate a revision to a patchset from Gerrit. Also in Gerrit the commit ancestry can be confusing if patches get modified out of order -- perhaps you've noticed that already.
...commits to be merged...
By the way, if it helps, don't think of your changes as being technically merged at completion. Consider them cherry-picked instead, and in this one's case for the master branch. Any change always becomes the very latest in the git log once we +2 and click submit, then anyone who uses git fetch will have a copy of your patch. The change in source for this commit would technically get "merged" out of existence because it's already in the source. And if it's cherry-picked, it should cause a message of "The previous cherry-pick is now empty..." (Hmm, it seems like Gerrit would want to flag that like it does a merge conflict...)