From: Junio C Hamano <gitster@pobox.com>
To: Fabian Stelzer <fs@gigacodes.de>
Cc: git@vger.kernel.org
Subject: Re: SubmittingPatchs: clarify choice of base and testing
Date: Mon, 25 Oct 2021 09:48:40 -0700 [thread overview]
Message-ID: <xmqqilxl2gpj.fsf@gitster.g> (raw)
In-Reply-To: <006c186e-c005-28a3-7a5c-27d365ffe026@gigacodes.de> (Fabian Stelzer's message of "Mon, 25 Oct 2021 10:59:53 +0200")
Fabian Stelzer <fs@gigacodes.de> writes:
> On 23.10.21 22:32, Junio C Hamano wrote:> * A new feature should be
> based on `master` in general. If the new
>> - feature depends on a topic that is in `seen`, but not in `master`,
>> - base your work on the tip of that topic.
>> + feature depends on other topics that are in `next`, but not in
>> + `master`, fork a branch from the tip of `master`, merge these topics
>> + to the branch, and work on that branch. You can remind yourself of
>> + how you prepared the base with `git log --first-parent master..`
>> + easily by doing so.
>
> Using the topic branches from gitster/git that were merged? Or by
> selecting the specific commits from the merge into next?
If I were doing this, I would find the tip(s) of things I would
depend on out of the output from
$ git log --oneline --first-parent origin/master..origin/next
This lists a series of merge commits and the second parent of each
merge commit is the tip of the topic that was merged to 'next'.
>> @@ -260,8 +281,8 @@ or include any extra files which do not relate to what your patch
>> is trying to achieve. Make sure to review
>> your patch after generating it, to ensure accuracy. Before
>> sending out, please make sure it cleanly applies to the `master`
>> -branch head. If you are preparing a work based on "next" branch,
>> -that is fine, but please mark it as such.
>> +branch head. If you are preparing a work based on selected topics
>> +merged to `master`, please mark your patch as such.
>
> I think this meant to say 'merged to "next|maint|seen"'?
> Or topics selected for being merged into master?
Ah, thanks for catching. I meant "not merged to 'master'" (will fix
locally).
Depending on stuff that are already in 'master', unless you are
preparing a fix that would also apply to the maintenance track, is
rather easy---you can just build on top of 'master'.
And in general, I do not want to see a new topic based on another
topic that is not yet in 'next'. If a developer has such a topic,
I'd appreciate if the developer waits and shifts their attention to
help the other topics they are planning to depend on---and one way
to do so is to review these other topics ;-)
Thanks.
next prev parent reply other threads:[~2021-10-25 16:48 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 3:39 [PATCH 00/11] midx: clean up t5319 under 'SANITIZE=leak' Taylor Blau
2021-10-21 3:39 ` [PATCH 01/11] midx.c: clean up chunkfile after reading the MIDX Taylor Blau
2021-10-21 5:50 ` Junio C Hamano
2021-10-21 11:34 ` Ævar Arnfjörð Bjarmason
2021-10-21 16:16 ` Junio C Hamano
2021-10-22 3:04 ` Taylor Blau
2021-10-21 3:39 ` [PATCH 02/11] midx.c: don't leak MIDX from verify_midx_file Taylor Blau
2021-10-21 5:00 ` Eric Sunshine
2021-10-21 5:54 ` Junio C Hamano
2021-10-21 16:27 ` Junio C Hamano
2021-10-21 3:39 ` [PATCH 03/11] t/helper/test-read-midx.c: free MIDX within read_midx_file() Taylor Blau
2021-10-21 3:39 ` [PATCH 04/11] builtin/pack-objects.c: don't leak memory via arguments Taylor Blau
2021-10-21 3:39 ` [PATCH 05/11] builtin/repack.c: avoid leaking child arguments Taylor Blau
2021-10-21 13:32 ` Derrick Stolee
2021-10-21 18:47 ` Junio C Hamano
2021-10-21 16:37 ` Junio C Hamano
2021-10-22 3:21 ` Taylor Blau
2021-10-21 3:40 ` [PATCH 06/11] builtin/multi-pack-index.c: don't leak concatenated options Taylor Blau
2021-10-21 3:40 ` [PATCH 07/11] pack-bitmap.c: avoid leaking via midx_bitmap_filename() Taylor Blau
2021-10-21 16:54 ` Junio C Hamano
2021-10-22 4:27 ` Taylor Blau
2021-10-21 3:40 ` [PATCH 08/11] pack-bitmap.c: don't leak type-level bitmaps Taylor Blau
2021-10-21 16:59 ` Junio C Hamano
2021-10-21 3:40 ` [PATCH 09/11] pack-bitmap.c: more aggressively free in free_bitmap_index() Taylor Blau
2021-10-21 5:10 ` Eric Sunshine
2021-10-21 18:32 ` Junio C Hamano
2021-10-22 4:29 ` Taylor Blau
2021-10-21 18:43 ` Junio C Hamano
2021-10-21 3:40 ` [PATCH 10/11] pack-bitmap-write.c: don't return without stop_progress() Taylor Blau
2021-10-21 5:12 ` Eric Sunshine
2021-10-21 11:31 ` Ævar Arnfjörð Bjarmason
2021-10-21 18:39 ` Junio C Hamano
2021-10-22 4:32 ` Taylor Blau
2021-10-23 20:28 ` Junio C Hamano
2021-10-23 20:32 ` SubmittingPatchs: clarify choice of base and testing Junio C Hamano
2021-10-23 20:59 ` Ævar Arnfjörð Bjarmason
2021-10-23 21:31 ` Junio C Hamano
2021-10-23 21:40 ` Junio C Hamano
2021-10-25 8:59 ` Fabian Stelzer
2021-10-25 16:48 ` Junio C Hamano [this message]
2021-10-25 16:56 ` Junio C Hamano
2021-10-25 17:00 ` Junio C Hamano
2021-12-23 23:12 ` [PATCH v2] " Junio C Hamano
2021-12-28 17:47 ` Elijah Newren
2021-12-30 10:20 ` Fabian Stelzer
2021-12-30 20:18 ` Re* " Junio C Hamano
2021-10-21 3:40 ` [PATCH 11/11] t5319: UNLEAK() the remaining leaks Taylor Blau
2021-10-21 11:50 ` [PATCH 00/11] midx: clean up t5319 under 'SANITIZE=leak' Ævar Arnfjörð Bjarmason
2021-10-22 4:39 ` Taylor Blau
2021-10-22 8:23 ` Ævar Arnfjörð Bjarmason
2021-10-22 10:32 ` [PATCH] leak tests: add an interface to the LSAN_OPTIONS "suppressions" Ævar Arnfjörð Bjarmason
2021-10-26 20:23 ` Taylor Blau
2021-10-26 21:11 ` Jeff King
2021-10-26 21:30 ` Taylor Blau
2021-10-26 21:48 ` Jeff King
2021-10-27 8:04 ` Ævar Arnfjörð Bjarmason
2021-10-27 9:06 ` Jeff King
2021-10-27 20:21 ` Junio C Hamano
2021-10-27 20:57 ` Ævar Arnfjörð Bjarmason
2021-10-29 20:56 ` Jeff King
2021-10-29 21:05 ` Jeff King
2021-10-27 7:51 ` Ævar Arnfjörð Bjarmason
2021-10-21 13:37 ` [PATCH 00/11] midx: clean up t5319 under 'SANITIZE=leak' Derrick Stolee
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqilxl2gpj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=fs@gigacodes.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.