From: Junio C Hamano <firstname.lastname@example.org>
To: Denton Liu <email@example.com>
Subject: Re: [PATCH v3 0/3] Teach submodule set-branch subcommand
Date: Fri, 08 Feb 2019 10:43:48 -0800 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <20190208053152.GA3378@archbookpro.localdomain> (Denton Liu's message of "Thu, 7 Feb 2019 21:31:52 -0800")
Denton Liu <email@example.com> 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
next prev parent reply other threads:[~2019-02-08 18:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 10:59 [PATCH " Denton Liu
2019-02-06 10:59 ` [PATCH 1/3] git-submodule.txt: document default behavior without --branch Denton Liu
2019-02-06 18:46 ` Junio C Hamano
2019-02-06 10:59 ` [PATCH 2/3] submodule--helper: teach config subcommand --unset Denton Liu
2019-02-06 19:07 ` Junio C Hamano
2019-02-06 10:59 ` [PATCH 3/3] submodule: teach set-branch subcommand Denton Liu
2019-02-07 6:32 ` [PATCH v2 0/3] Teach submodule " Denton Liu
2019-02-07 6:32 ` [PATCH v2 1/3] git-submodule.txt: document default behavior without --branch Denton Liu
2019-02-07 6:32 ` [PATCH v2 2/3] submodule--helper: teach config subcommand --unset Denton Liu
2019-02-07 6:33 ` [PATCH v2 3/3] submodule: teach set-branch subcommand Denton Liu
2019-02-07 10:18 ` [PATCH v3 0/3] Teach submodule " Denton Liu
2019-02-07 10:18 ` [PATCH v3 1/3] git-submodule.txt: "--branch <branch>" option defaults to 'master' Denton Liu
2019-02-07 10:18 ` [PATCH v3 2/3] submodule--helper: teach config subcommand --unset Denton Liu
2019-02-07 20:05 ` Junio C Hamano
2019-02-07 22:29 ` Junio C Hamano
2019-02-07 10:19 ` [PATCH v3 3/3] submodule: teach set-branch subcommand Denton Liu
2019-02-07 22:26 ` Junio C Hamano
2019-02-07 18:01 ` [PATCH v3 0/3] Teach submodule " Junio C Hamano
2019-02-08 5:31 ` Denton Liu
2019-02-08 18:43 ` Junio C Hamano [this message]
2019-02-08 11:21 ` [PATCH v4 " Denton Liu
2019-02-08 11:21 ` [PATCH v4 1/3] git-submodule.txt: "--branch <branch>" option defaults to 'master' Denton Liu
2019-02-08 11:21 ` [PATCH v4 2/3] submodule--helper: teach config subcommand --unset Denton Liu
2019-02-08 11:21 ` [PATCH v4 3/3] submodule: teach set-branch subcommand Denton Liu
2019-02-08 23:51 ` Denton Liu
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this inbox:
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).