"Linux kernel developers have gain given Linus Torvalds cause for complaint."
Is this "cheeky" British "slang" (or "chuffing")? Can you translate for those of us "across the lorry"?
Linux kernel developers have again given Linus Torvalds cause for complaint. The Linux Lord felt the need to take to the Linux Kernel Mailing List late last week to tell a chap called Wolfram Sang that “If you cannot explain a reason for a merge or be bothered to try to write a commit message, you shouldn't be doing that merge …
“If you cannot explain a reason for a merge or be bothered to try to write a commit message, you shouldn't be doing that merge. It really is that simple.”
That seems uncharacteristically polite. I'd say it more like “If you cannot explain a reason for a merge or be bothered to try to write a commit message, you shouldn't be touching anything in source control at all."
Sigh... at least one person got the XKCD reference. It's a sarcastic nod to the impression that Linux developers work on esoteric features that don't have real world applications while ignoring usability concerns that, if corrected, could lead to greater adoption among ordinary computer users. A 256 terabyte memory limit isn't a concern for most end users.
"A 256 terabyte memory limit isn't a concern for most end users."
OTOH Linux does run almost all the world's supercomputers. They might need it.
If you limit what an OS can do to what "most" end users need then you might not get much beyond Firefox OS. You might also conclude that 640K is enough for anybody.
Yep. That's why I said "most end users". Again, the knock is that there's more focus on the exciting edge cases and not on the mundane end user experience. If you limit your efforts to the edge cases, you might not get much beyond those edge cases. That's part of why the Year of Linux on the Desktop is always 2 years away.
What I would like to know is:
Who's got the machine to test that everything works with 128PB of memory and how long does the memory test take? Perhaps this will delay the release waiting for the test(s) to complete.
Some sort of clustering arrangement - I would think - maybe?
"Particularly don't do merges when they turn a single commit into *four* commit (original, revert, merge, and alternate) and have bad explanations for half of those.”
[snip]
“you want to do the pull to sync up or something, don't do the revert, but instead make the merge message talk about *why* that merge was done.”
“Since the *only* possible reason for that pull seems to have been to make some git history match up, it damn well matters what the git history is, and these commits should make sense. As it is, the history just looks messy with bogus explanations.”
gibberish.
I think what he's moaning about is the fact that pretty much anyone who uses git - myself included - finds it incredibly tedious. But of course Lord Torvalds won't have that, because it's another one of his creations.
If you search for "git man pages generator" there's a web page which generates random gibberish, however, it's so similar to the *real* documentation that you can't really tell it's satire.
Maybe the tools you've come up with are a load of bullshit, and that's why people are going against your particular way of working, Linus?
Er, no. Perhaps it's just that people submitting code haven't actually bother to lean how to submit code.
git is a PITA a lot of the time, but it is the Linux kernel SCCS. So, if you want to submit stuff, learn how to do it. It's not, actually, that difficult, to learn the minimal subset of commands required to do this properly.
I use git, and don't find it tedious. It's very good at doing what it does - managing multiple changes to large source-code repositories. Like all good tools, it's flexible, and can be used in a variety of ways.
I find that "git" becomes a problem in organisations that held the expectation that adopting a popular source-control tool would make up for their lack of a source-control process.
Usually, these places not only adopt git but then they follow that up by cribbing the workflow of the Linux kernel, it being the most famous project to use git. The result: people get mired in a pointless bureaucracy that makes sense for a globally-distributed contributor model, but is utterly insane for one office with twenty developers in it.
Like everything in tech, those in charge of the decision then focus on the tool rather than look at the way it was used. No doubt whenever something cooler than git arrives, everyone will jump on that and make the same mistakes there.
(Just look at how everyone who couldn't design a proper web application in PHP, C# or Java has now given way to people to building the same unmaintainable rubbish web applications in Rust, Rails, Go or Node... )
"pretty much anyone who uses git - myself included - finds it incredibly tedious."
the (informal) survey says: WRONG!
I use git somewhat frequently and it's simple enough. "git commit ." (edit message) "git push" (enter login info). NOT hard, assuming you're not on windows...
[maybe win-10-nic doesn't have a UWP stoopid-GUI for it in "the Store" yet]
It's been apparent for a long long time that our need for competent people far outstrips the supply. You could see what I call "contemptuous usage" in software engineering tools at any time since, oh, 1980. At any given point in time, the quality of the tech population followed Sturgeon's Law. The population increased over time to match the demand, but the quality level didn't improve.
LT would be well advised to get draconian about commits, requiring at least some coherent explanation, and especially refs to whatever bug or requirement is being addressed. Heck, there's even some AI around these days that could be set to analyzing comments.
I find git "needless" merges tedious as well.
The solution is to tell your git to always pull with the --rebase option. These is a global config option to do that. Then git will first save all the commits you have locally, rewind back to last pull state, then pull and fast-forward to latest at the remote, and then replay your commits. If you did something that requires conflict resolution, git will then let you do that locally, and the other contributors will not have to suffer your mess.