Re: [PATCH v3 0/3] Teach submodule set-branch subcommand
- Date: Fri, 08 Feb 2019 10:43:48 -0800
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH v3 0/3] Teach submodule set-branch subcommand
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.
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)
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
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
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