Live data from Hacker News

Linus Torvalds did not commit this

github.com

191–198 of 198 posts

Re: Linus Torvalds did not commit this

#191
post #169

Earlier quoted context omitted.

But that's exactly how you presented their supposed argument: "Caltech students don't cheat because they're not representative of the general student population", with the vague assumption that Caltech students are more honour-bound. Not being representative of a population doesn't give any information about the makeup of the subsample, unless you have more information to add.

> But that's exactly how you presented their supposed argument: "Caltech students don't cheat because they're not representative of the general student population" No, its not, which is why you had to present a "quote" that isn't to advance that story. I presented how they would reject an argument from the general population, not positive argument for the absence of cheating at Caltech.

What are you talking about? You presented the argument as a potential rebuttal to the claim that students cheat. It's inherently implied that it's an argument for the absence of cheating at Caltech... otherwise it wouldn't be a rebuttal at all, and instead is a non-sequitur fallacy.

Yes, if you strip away the context of the literal words you said, you're correct. But in context, you're not.

Re: Linus Torvalds did not commit this

#192
post #143

Earlier quoted context omitted.

> The professor replied back that he was very sorry and was forced to give him an F. The student repeated the (required) class next year. Wow, way to prize process over people. Why not let the student drop the class and just re-take the test next time around? Is Caltech designed to teach science, or train paper-pushers?

You could at least ask the student how much time they took actively working on the exam, less the part where they fell asleep, and compare that to the time limit.

The awake time spent on the test was under the time limit. The wall time was a few hours over.

Re: Linus Torvalds did not commit this

#193
post #183
post #143

Earlier quoted context omitted.

> The professor replied back that he was very sorry and was forced to give him an F. The student repeated the (required) class next year. Wow, way to prize process over people. Why not let the student drop the class and just re-take the test next time around? Is Caltech designed to teach science, or train paper-pushers?

In my day (ca. 2000) there was no "forced to give an F" and in fact it was very common for exam-takers to draw a line, write "everything below this line I did after the time limit", and get partial credit for it.

Not that I recall. I don't think it's quite fair to do that, as it then becomes an infinite time exam.

But also consider that the midterm and the final were the entire grade. No credit was given for homework, showing up for class, etc. The rules about the exams were pretty clear.

However, if you had a borderline exam grade, but had done the homework diligently, the prof would use that as a tie breaker.

His fellow students thought the F was a bit harsh, but he conceded that it was fair and took his lumps with equanimity. I quite admired him for it. In the end, it didn't hurt him because he graduated and went on to a very successful career.

Re: Linus Torvalds did not commit this

#194
post #99

Earlier quoted context omitted.

You’re doing a rebase, which is not the same thing as purposely editing the commit author credentials.

Negative, we're actually editing the commit author credentials when we create the final commit message, which adds a Changelog message and closes the original PR. https://github.com/videojs/video.js/blob/master/contrib.json...

Why not just doing a rebase? I work on a big open-source project on Github and we do rewrite/squash commits to have a clean history, but it only involves a rebase, not editing the author credentials.

Re: Linus Torvalds did not commit this

#195
post #110
post #90

Earlier quoted context omitted.

[deleted]

Finding the exploit and taking advantage of it are different. "I discovered that if you rip the tags out of a library book, you can just walk out with it and the alarm won't go off!" For some people, that would be a significant "a-ha!" moment. That doesn't mean they should go around stealing library books.

> "I discovered that if you rip the tags out of a library book, you can just walk out with it and the alarm won't go off!"

I recently went on a tour of my former university's new library building.

One thing that surprised me was that all the upper floors are set about six feet back from the exterior windows ( leaving an internal building-height vertical gap all the way around, so you can look over the railing down to the ground floor ).

When I enquired about this, the response was that it was to prevent the throw-book-out-of-window-and-collect-it-later trick that was apparently common with the old building!

Re: Linus Torvalds did not commit this

#196

Earlier quoted context omitted.

By appending "unverified" and "unsigned" after the email addresses? Just like email. This problem has been solved long ago, there is no reason why Git can't fix this. It already has PGP signatures, there is no reason to not add verification layer.

> [Git] already has PGP signatures, there is no reason to not add verification layer. It already does. man 1 git-verify-commit man 1 git-verify-tag This is a Github problem.

You can run those commands by cloning that repo. The issue here is that emails can still be spoofed while looking at the commit, without running the command.

Why do you think that seeing a username on Github is any different that seeing an unverified email in any other hosted Git repo? You need to git-verify in both cases. It is your own misunderstanding that seeing a username on Github implies it's verified. It's not. Just like looking at email is not on Git.

Re: Linus Torvalds did not commit this

#197

Earlier quoted context omitted.

> [Git] already has PGP signatures, there is no reason to not add verification layer. It already does. man 1 git-verify-commit man 1 git-verify-tag This is a Github problem.

You can run those commands by cloning that repo. The issue here is that emails can still be spoofed while looking at the commit, without running the command. Why do you think that seeing a username on Github is any different that seeing an unverified email in any other hosted Git repo? You need to git-verify in both cases. It is your own misunderstanding that seeing a username on Github implies it's verified. It's no…

> Why do you think that seeing a username on Github is any different...

I don't.

> It is your own misunderstanding that seeing a username on Github implies it's verified.

I'm not confused. Others appear to be. My comment was in reply to a poster who seemed to be indicating that git lacked the ability to verify signed commits and tags.

I was informing him that git does indeed have that ability, and that its absence from GitHub is a GitHub problem, not a git problem.

You've leapt to an entirely unsupportable conclusion about my familiarity with git and commit/tag signing. :)

My informal, entirely unscientific survey of folks who use GitHub leads me to believe that they are -on average- less proficient with git, git concepts, and the notion of cryptographic signing than the average person who uses the git CLI.

This [0] appears to be the closest that the GH documentation gets to saying "anyone can commit with anyone else's email address". Adding support and graphics for tag and commit signature verification -along with support for tag/commit signing in the GitHub client- might be a nice thing to do for users who are not so familiar with git.

Oh, also:

> You need to git-verify [to verify unverified email addresses attached to git commits] in both cases.

git-verify-* is actually only useful on signed commits/tags. If a commit/tag hasn't been signed, it exits with a non-zero exit code and does nothing else. Given that the vast majority of commits one will run into will not be signed, git-verify-* typically won't help you to determine the validity of the authorship of a commit/tag. Reading the -very short- man page of either command would have caused you to understand this. :)

[0] https://help.github.com/articles/why-are-my-commits-linked-t...

Re: Linus Torvalds did not commit this

#198
post #123

Unfortunately so far the same is possible for gitlab too. Isn't it the general problem that each user is authenticated as the "git" user and the rest (all the git commands) is just "user.name" and "user.email" fields in prefs?

They could identify users by their auth and store that data with the commits instead of relying on the user email. You either have to provide username/password, API token, or ssh key to push to a github repo. All of these identify you as you.

Edit: It is important to note that this would not replace git authorship info as it is very possible that you pushed something that someone else committed. It would allow you to have a UI trail to who pushed it which could help if you theorize that someone is impersonating someone else.

Post reply on HN