Our Git FAQ1 currently says (at the bottom):
What about commits that should not be merged upwards (say, only for 5.3)?
Should you still merge them but make it so no changes actually take place?
Otherwise, it will the next person merging that will have to deal with the
conflict (or worse, the changes will be merged when they shouldn't have
been)
Please, could someone supply examples as to when this scenario occurs, and
how to handle it?
Our Git FAQ[1] currently says (at the bottom):
What about commits that should not be merged upwards (say, only for 5.3)?
Should you still merge them but make it so no changes actually take place?
Otherwise, it will the next person merging that will have to deal with the
conflict (or worse, the changes will be merged when they shouldn't have
been)Please, could someone supply examples as to when this scenario occurs, and
how to handle it?I routinely do this for version commits on my release branch.
See:
https://github.com/php/php-src/commit/4fa32d67bf3fbea0241f0e786dbcb5517d25e1a2
Or cmb here:
https://github.com/php/php-src/commit/2d93cce03a96ee7b0265e15e2d56acd173dec682
In both cases, we do the commit on our branch, then nullify it in the first
merge, then have null merges the rest of the way down.
-Sara