On Fri, Jul 28, 2023 at 08:22:22AM +0200, Oscar Megia López wrote: > Yes, I read > https://www.kernel.org/doc/Documentation/process/submitting-patches.rst > yesterday and more online documentation and I didn't find any describing the > correct way to send next patch version. > > Today I found this > https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/ > but I still have some doubts. What you're running into is the fact that there are multiple ways that people will prepare patch versions, and so the process documentation merely specify what the patch series should look like. > Yes, I know, but I want to know how an expert programmer send > next version (create new branch for each patch's version?, create new > directory outgoing for each patch's version?, run git pull on patch's > branch?, add --in-reply-to= to previous patch's version email? > ¿cover letter or 1/1?, etc.). Not only do many experienced programmers might have different perferred workflows, they might use different procedures depending on how complex the patch series would be. For example, for the case for a single patch, I'd probably just use "git format-patch -1 ...", meaning "just format the top-most patch on the current branch". For a really simple patch, I might just use "git commit --amend" to make changes, and I might not bother rebasing unless it was necessary to make sure it would apply on the top of the development branch. If it was necessary to rebase, assuming that you have the local branch "origin_<topic>" which points as the base to your patch or patch series, then what *I* typically do is just do: git branch -f orgin_<topic> origin/master git rebase origin_<topic> Now the topic branch is rebased on the tip of the upstream development branch, and now I might just do: git format-patch -o /tmp/p origin_<topic>.. For a single patch, I might not bother with cover letter, and most of the time, I'll just manually copy the cover letter from the previous version into the current cover letter, append the description of what changed from the last version, and then I'll send it out. This just uses all basic git commands. There *are* more sophisticated systems that will automate things, and it's completely up to you whether or not you want to use them. Sometimes, the simpler methods are best and systems which try to "automate" things can just confuse you. If you want to see an example of a much more sophistcated system, take a look at the b4's "prep" command[1]. I don't use it, my self, although I do use "b4 am" and "b4 ty" for my maintenance work. So don't feel like you have to use "b4 prep"; try it out, and see if it makes your life easier. If so, use it! If not, just let it go, and try something else. [1] https://b4.docs.kernel.org/en/latest/contributor/prep.html Finally, with respect to your original patch. My apologies for not looking at it eariler. I'm pretty swamped these days, which means that I'm prioritizing which patches get my attention. As far as this particular patch, I don't think it's actively harmful, but I also don't quite see the point. If you want to see how full a file system might be, and it's disappearing too quickly because shortly after fsck finishes, the graphical login has come up, you can always use the "df" command, right? - Ted
