Re: SubmittingPatchs: clarify choice of base and testing

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 25, 2021, 16:48 UTC
Message-ID: <xmqqilxl2gpj.fsf@gitster.g>
In-Reply-To: <006c186e-c005-28a3-7a5c-27d365ffe026@gigacodes.de>

Fabian Stelzer <fs@gigacodes.de> writes:

Show 12 quoted lines

> 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'.

Show 11 quoted lines

>> @@ -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.