Denton Liu <liu.denton@xxxxxxxxx> writes: > By the way, just for the record, how would you like me to handle > patchsets that cause merge conflicts? When it happens, I may ask you to rebase onto a specific commit. https://public-inbox.org/git/xmqq5ztxstkh.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/ is a recent example. My preference (read: I'd be grateful if contributors tried to stick to it, but it won't be the reason for patch rejection if they don't) is: 1. Choose the right base: a) For a fix to a bug that already exists in the last feature release (i.e. v2.20.0), build on 'maint' and make sure it merges cleanly to 'master', and the merge result builds and passes tests. Depending on the severity of the bug, we might want to make sure that the fix applies maintenance track even older, but it would be something you would be sending patches to git-security mailing list---over there we'll figure out the right base on case-by-case basis. b) For a new feature, build on 'master', if you can. c) If you need to use something (i.e. a new helper function, updated type, etc.) in 'next' that is not yet in 'master', identify the topic(s) that introduces these things you need, merge them to 'master' and build on top of it. If you did so, please note in the cover letter what topics you depend on. d) When updating a topic that is already in my tree (i.e. rerolling), stick to the same base as the previous round, if possible. You can find out the commit the previous round was applied on top by fetching from me. Your reroll may start using something the previous round did not use from 'next', in which case you may end up doing c) above, which is OK. Just make a note in the cover letter to let reviewers know. 2. Make sure the result builds and passes tests. 3. Make sure the result merges cleanly to 'next', and the merge result builds and passes tests. 4. In any of the above steps where you are asked to "make sure it merges cleanly", you may see merge conflicts. a) If they are too much to resolve for you, for a change that is not a bugfix, you may have to depend on the other topic(s). Identify the topic(s) that touches these lines that heavily conflict with your changes, merge them to 'master' and base your topic on top of it (i.e. going back to step 1.c). b) If they are easy to resolve for you, do not worry too much about them. It may be helpful to note in the cover letter "this may have minor textual conflict with these other topics". c) If you are left with huge conflict while working on a bugfix change, we need to resolve it on case-by-case basis, so send it out with the chosen base. Noting that it conflicts heavily with 'master' or 'next' would be very much appreciated when this happens. Thanks.
