Re: SubmittingPatchs: clarify choice of base and testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Fabian Stelzer <fs@xxxxxxxxxxxx> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux