Git FAQ - "How to handle changes that should not merge upward?"

  105733
May 17, 2019 14:55 bishop@php.net (Bishop Bettini)
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? [1]: https://wiki.php.net/vcs/gitfaq
  105734
May 17, 2019 15:29 pollita@php.net (Sara Golemon)
On Fri, May 17, 2019 at 9:56 AM Bishop Bettini <bishop@php.net> wrote:

> 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