On 4/10/20 10:25 AM, Linus Torvalds wrote: > On Fri, Apr 10, 2020 at 7:37 AM Jens Axboe <axboe@xxxxxxxxx> wrote: >> >> This one sits on top of the previous, figured that was easier than >> redoing the other one fully. > > It's actually easier for me if you remove the broken tag when you > notice things like this (or use the same name for the fix tag and just > force-update it). > > And then send a "oops, me bad, I updated it" with the new pull data. > > The reason: when I opened this thread, I didn't notice your follow-up > at first, so I pulled the old tag, and so got the known-broken code. > > And yes, I double-checked and caught it, unpulled and then re-pulled > the fixed-up tag instead. > > But if the wrong tag had been just overwritten or deleted, the extra > steps wouldn't have been necessary. > > Not a huge deal, it's not like it took me a lot of effort (it's more > painful if I have to fix up conflicts twice, although even that isn't > usually much of a bother since the second time I don't have to really > analyze them again). > > So just a heads up for "I wish you'd done X instead". Noted! Since I sent out this pull yesterday and I knew I'd be away from a keyborad all day today, I had to rush this followup pull this morning. Normally I probably would have killed the branch and sent a new one. Thanks for doing the right thing, and just pulling the new tag instead. > Btw, on the subject of "I wish you had done X": this is not at all > particular to you, and a lot of people do this, but pull requests tend > to have the same pattern that we are trying to discourage in patch > descriptions. > > So in Documentation/process/submitting-patches.rst, we talk about this: > > "Describe your changes in imperative mood, e.g. "make xyzzy do frotz" > instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy > to do frotz", as if you are giving orders to the codebase to change > its behaviour" > > because once it's then accepted into git, the whole "this patch" kind > of language doesn't really make much sense. It's much better to just > describe what the change does, than say "this change does X". > > The same is actually true when I merge your pull request, and I take > the description from your email. Because the same way "This patch does > X" does not make a regular commit message any more legible, the "This > pull request does X" does not make sense in the commit message of a > merge. > > So I end up editing peoples messages a lot (and I occasionally forget > or miss it). > > Again, this is _not_ a huge deal, and I obviously haven't made a stink > about it, but I thought I'd mention it since I was on the subject of > "this causes me extra work". I like it, I'll word my pull requests imperatively going forward. -- Jens Axboe
