On Thu, May 27, 2021 at 10:25 PM Alex Bennée <alex.ben...@linaro.org> wrote: > > > Takashi Yamamoto <yamam...@midokura.com> writes: > > > On Tue, May 25, 2021 at 8:22 AM Takashi Yamamoto <yamam...@midokura.com> > > wrote: > >> > >> On Tue, May 25, 2021 at 2:49 AM Alex Bennée <alex.ben...@linaro.org> wrote: > >> > > >> > > >> > YAMAMOTO Takashi <yamam...@midokura.com> writes: > >> > > >> > > These patches, along with a few more hacks [1] I didn't include > >> > > in this patchset, allowed me to run arm64 and armv7 version of > >> > > dind image on amd64. > >> > > > >> > > [1] https://github.com/yamt/qemu/tree/linux-user-for-docker > >> > > >> > Might be worth posting those patches next time (even if they have a RFC > >> > or !MERGE in the title for now). > >> > >> ok. > > > > while RFC is mentioned in eg. git format-patch --help, > > i couldn't find what !MERGE is. > > can you provide a reference? > > It's usually just an annotation to the subject line of the commit, e.g: > > foo/bar: hacky fix to frobulator (!MERGE) > > rest of commit message > > or something like: > > baz/quack: invert the tachyon beam (WIP) > > reason for the fix. > > [AJB: still WIP as this breaks foo] > > AFAIK the only subject lines supported by the tooling are the squash: > and fixup: prefixes. > > > is there a nice way to express that some patches in a post are meant > > for application and the others are RFC? > > Aside from a description in the cover letter not really. The main reason > to include patches that aren't ready for merging is to show where your > work is going so the full context of earlier changes can be seen. Having > an ALL CAPS tag in the subject line is just handy for the maintainer > when scanning what might get cherry picked. Obviously if a patch totally > breaks the build it's not worth including as it just makes review harder > when giving the patches a spin so you should exercise your judgement.
ok. thank you for the explanation. > > -- > Alex Bennée
