Re: [PATCH v3 0/3] Teach submodule set-branch subcommand

Denton Liu <liu.denton@gmail.com> writes:

When it happens, I may ask you to rebase onto a specific commit. https://public-inbox.org/git/xmqq5ztxstkh.fsf@gitster-ct.c.googlers.com/ 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.