LWN: Comments on "Patch flow into the mainline for 4.14"

Patch flow into the mainline for 4.14

mathstuf — Sat, 28 Oct 2017 00:10:27 +0000

There's the -x flag to cherry-pick to do that. Note that conflicts will trip this up.

Patch flow into the mainline for 4.14

epa — Fri, 27 Oct 2017 19:36:40 +0000

Agreed! Another reason is to pick out a particular change without all the ones that went before it. So, given a particular commit and the other one it was cherry-picked from, it should be possible to check that the diff is the same, while ignoring the commit message, whitespace changes in the file content and other things which cause the SHA to be different but aren't important for this comparison.

Patch flow into the mainline for 4.14

Creideiki — Fri, 27 Oct 2017 16:40:44 +0000

It kind of is, if you want to do it properly. I have some scripts (available at https://github.com/saab-simc-admin/workflow-tools) for maintaining an all-signed workflow, and the amount of corner cases and badly designed interfaces I have to handle is staggering.

Not to mention the fact that since nobody uses signatures, the code isn't tested - libgit2 (which is, among other things, the base for Ruby's Git support) used to corrupt the plaintext of signed commits due to a use-after-free bug.

Patch flow into the mainline for 4.14

seanyoung — Fri, 27 Oct 2017 15:10:53 +0000

One of the reasons for cherry-pick is to be able to drop patches, fix commit messages or other cosmetic changes that maintainers do sometimes.

Patch flow into the mainline for 4.14

JFlorian — Fri, 27 Oct 2017 12:45:40 +0000

In general use of gpg-agent, I wish the cache time could be dynamic. So, say it starts with a default of 10m. I use it immediately for a key and then again at 8m into that lifetime. Here it would be nice to get an automatic extension of another 8m and so on until it does finally timeout due to no use. I think that would be much more convenient and likely more secure simply because might mean fewer people use reall high timeout values. Better convenience might also translate to higher adoption rates.

Patch flow into the mainline for 4.14

epa — Fri, 27 Oct 2017 10:00:00 +0000

Could git grow some secondary checking for cherry-picked commits? Like, the commit would say 'cherry-picked from abcde' and then you could optionally run something which makes sure the diff being applied in this commit is the same as that from abcde. If not, it would be flagged for extra attention.

Patch flow into the mainline for 4.14

flussence — Fri, 27 Oct 2017 03:37:16 +0000

Signing in git really isn't as hard or scary as people think it is. Make a key if necessary, configure gpg-agent so it caches key passwords for at least a few seconds (or else rebases will be painful), and set commit.gpgSign.

The only recurring effort is re-entering passwords, but there's nothing to stop you setting gpg-agent's cache time really high if it gets annoying.

Patch flow into the mainline for 4.14

ajdlinux — Wed, 25 Oct 2017 23:56:27 +0000

Maybe in some subsystems. Not the case kernel-wide.

Patch flow into the mainline for 4.14

smurf — Wed, 25 Oct 2017 16:28:27 +0000

> There are way too many eyeballs for anything to slip through.

Not if the threat model includes innocuous-seeming feature patches which include non-features.

Numerous contests have been held on the topic of how to write C code with obfuscated, plausibly-deniable security holes.

Patch flow into the mainline for 4.14

seanyoung — Wed, 25 Oct 2017 10:13:35 +0000

Every commit on every pull request is reviewed and cross-referenced with the corresponding patch on patchwork. Then, on top of that, the original submitter and sub-maintainer will likely check what goes into master.
There are way too many eyeballs for anything to slip through.
This is not a problem.

Patch flow into the mainline for 4.14

unixbhaskar — Wed, 25 Oct 2017 02:59:56 +0000

Making all commit from everyone as mandatory to be signed..otherwise refused to be pulled in or merged in the mainline.Sounds harsh, but that is what it should be.I believe may wise heads are there already thinking in that line and am surprised not yet imposed or implemented. Love to know the constraints.

Patch flow into the mainline for 4.14

nevets — Tue, 24 Oct 2017 20:54:22 +0000

Ug, That's even worse with respect to security. Unless you scrutinize each patch that is cherry picked, then it's no different than a work flow that takes only patches from email.

Patch flow into the mainline for 4.14

seanyoung — Tue, 24 Oct 2017 18:46:54 +0000

Note that merge requests for the media tree are cherry-picked, not merged. I guess this is why the linux-media patch flow has no children in the graph.