Pushing code to GitHub as Linus Torvalds(jayhuang.org)
jayhuang.org
Pushing code to GitHub as Linus Torvalds
http://www.jayhuang.org/blog/pushing-code-to-github-as-linus-torvalds/
26 コメント
This is one of many reasons why we still use SVN. Every commit is authenticated against our LDAP server so is technically signed against a user based on their credentials.
... you can sign your git commits with GPG, which is a hell of a lot better than "technically signed" via random internal LDAP and implied relationships.
Git has an intentional separation between author of a commit, and the person who signed-off on it. So if you hired an outside contractor to work a little bit of code, he could write it, send it to you, and then an internal person with a GPG key would review it and sign-off on it. It would retain the original author (contractor) and it would retain the person who put it into your code and "signed off" on it.
What other non-reasons do you have for using SVN?
Git has an intentional separation between author of a commit, and the person who signed-off on it. So if you hired an outside contractor to work a little bit of code, he could write it, send it to you, and then an internal person with a GPG key would review it and sign-off on it. It would retain the original author (contractor) and it would retain the person who put it into your code and "signed off" on it.
What other non-reasons do you have for using SVN?
It's a hell of a lot simpler if you don't need a ton of branches, and better integrated with Windows.
There are lots of wonderful integrations / applications for windows now. The days of windows being awful with Git are behind us.
Hell of a lot simpler if you don't need ANY branches. Merging is still a goddamn nightmare with SVN.
Hell of a lot simpler if you don't need ANY branches. Merging is still a goddamn nightmare with SVN.
> There are lots of wonderful integrations / applications for windows now. The days of windows being awful with Git are behind us.
Please tell me more, how I can get behind Git being awful on Win7 since I have to use this OS at work (and since I've been on Linux personally for a few years, I have no clue). I have only some crappy git console and my config even doesn't work outside of it. Thank you.
Please tell me more, how I can get behind Git being awful on Win7 since I have to use this OS at work (and since I've been on Linux personally for a few years, I have no clue). I have only some crappy git console and my config even doesn't work outside of it. Thank you.
msysgit + tortoise git make it pretty simple, and Visual Studio 2013 has built in git support (however I've not used it very much)
I don't use VS, and as it turns out, the crappy console I'm talking about is this msysgit. The lack of a decent consistent terminal is my biggest pain in win7. cmd, powershell, msysgit - they all are total crap and every one works differently. And my Git settings aren't working from Eclipse, basically the only place they work is this git terminal. Sorry, but that's not 'wonderful integration'. On Linux everything just works.
Really? In my Linux experience it's a lot more rare for things to 'just work' than on Windows. Windows' homogenous environment contributes to this.
If by "things" you mean customer software support then yes, but development environments work consistently and are dead easy to set up. YMMV if you work on MS tech (.net, etc.), I don't. TBH one of my main reasons to move to Linux a few years ago is because I was pissed off by this particular problem (how to do it + ok and now tell me how to do it on windows and why half of what you describe doesn't work).
as i said, try tortoise git. msysgit is just the underlying git environment, and is pretty much the same as git on linux. tortoise git is the GUI front end and windows integration bit that makes it nice and usable.
cmd/powershell are horrible, so just install cygwin and ignore them. it gives you a fully functional bash shell with a package manager and the majority of the common Linux utilities and plays nice with windows CLI programs.
I cannot comment on Eclipse, but with msysgit + tortoise git, git pretty much just works in windows and integrates so well even our non technical staff (designers, QA etc) use it without any issues.
cmd/powershell are horrible, so just install cygwin and ignore them. it gives you a fully functional bash shell with a package manager and the majority of the common Linux utilities and plays nice with windows CLI programs.
I cannot comment on Eclipse, but with msysgit + tortoise git, git pretty much just works in windows and integrates so well even our non technical staff (designers, QA etc) use it without any issues.
What do you use? I use SourceTree and it's slow and buggy. TortoiseSVN was the best versioning client experience I'd had. TortoiseGIT didn't do as well.
How many people other than developers can handle GPG? We have office staff, graphic designers, operations and technical authors as well using SVN. About 100 people and several separate repositories.
sAMAccountName is passed through transparently from users' NT accounts using NTLM. Relationships are also very strongly enforced with access to their own workstations tied down.
Other non reasons:
1. partial checkouts.
2. Easy ACL control.
3. Great tooling for windows
4. Locking (oh the sin) - we have numerous unmergeable binary files like PSDs going in as well.
5. No problems with large bins like reference DLLs and graphics.
6. Bomb proof with a top end repo size of 14G and 100000 revs and NO problems reported.
7. Centralised commit policy. We have scripts that test check ins for stupid things people have done, bad ticket references etc.
I could go on.
It works very well for us (oh and we don't have merge tracking problems for reference).
sAMAccountName is passed through transparently from users' NT accounts using NTLM. Relationships are also very strongly enforced with access to their own workstations tied down.
Other non reasons:
1. partial checkouts.
2. Easy ACL control.
3. Great tooling for windows
4. Locking (oh the sin) - we have numerous unmergeable binary files like PSDs going in as well.
5. No problems with large bins like reference DLLs and graphics.
6. Bomb proof with a top end repo size of 14G and 100000 revs and NO problems reported.
7. Centralised commit policy. We have scripts that test check ins for stupid things people have done, bad ticket references etc.
I could go on.
It works very well for us (oh and we don't have merge tracking problems for reference).
I can set the From: field of an e-mail to <[email protected]> and similarly impersonate Linus in an e-mail. Clearly e-mail is broken.
Many would argue that email IS broken.
If a solution to this is really needed (which seems somewhat dubious), github could allow people to register pgp public keys with their account and then users could sign their commits. Github could then indicate that a commit is verified as being from that user.
Git already has this, it is already a thing, since 1.7.9. I can sign my commits, you can validate my signature, if we both care, it is out there already.
I'm aware. I'm saying github could provide an interface to indicate verified signatures to the github account. It's because git has signed commits that this suggestion is even possible.
'I understand this feature has the benefits of allowing people to push commits with emails they don’t own, such as ‘[email protected]’ that I occasionally use, but having your commits attributed to a different user is a whole different issue.'
More than that it makes it so the distributed nature of Git is preserved. If I pull from someone who committed a bunch of stuff under their own name but isn't a user on GitHub, then push up to GitHub, GitHub won't be able to just reject the commits from the user who is not on GitHub - it will have to reject the push entirely. Thus, there is no way around this without losing all the benefits of Git.
Perhaps a way around it would be to sign all commits where the committer has the same email address as an existing GitHub user, and then check the signature against the GitHubber's known key, and reject it if the signature doesn't check out.
But having to sign commits if you are a GitHub user adds extra hasssle, and what if an unsigned commit accidentally makes its way into the history? What a pain. Everyone would always have to commit with the possibility of being able to be pushed up to GitHub in mind.
More than that it makes it so the distributed nature of Git is preserved. If I pull from someone who committed a bunch of stuff under their own name but isn't a user on GitHub, then push up to GitHub, GitHub won't be able to just reject the commits from the user who is not on GitHub - it will have to reject the push entirely. Thus, there is no way around this without losing all the benefits of Git.
Perhaps a way around it would be to sign all commits where the committer has the same email address as an existing GitHub user, and then check the signature against the GitHubber's known key, and reject it if the signature doesn't check out.
But having to sign commits if you are a GitHub user adds extra hasssle, and what if an unsigned commit accidentally makes its way into the history? What a pain. Everyone would always have to commit with the possibility of being able to be pushed up to GitHub in mind.
Commits not pushed with a user's public key could be marked as unverified in the web UI until the logged-in user verifies ownership.
That is just how git works, and there isn't really anything GitHub can do about it. Marking commits as being by the person who pushed them rather than being by the person who wrote them is the closest you could come, and that would be terrible. It's not even really fixable in a DVCS at all short of not supporting unsigned commits.
I don't think this is a problem with GitHub, it is - if you want to call it a problem at all - a problem with git itself because noone stops you from using any email adress and name as user.email and user.name in your git config. You could do the same thing on bitbucket, your companys git repositories, git repositories on your own server etc.
Coincidentally, I just tried this on Bitbucket a couple of days ago. For your activity feed, it must check the username you used to authenticate when you pushed, not what email address is on the commit. The activity feed on my profile says the commit is mine -- however, when viewing the commit, it says it's by the other person whose email address I used. Not sure if GitHub does the same thing.
I remember reporting impersonation as a problem to the gitolite project years ago and was told in no uncertain terms that I just didn't understand the distributed nature of git (which was true at the time).
If you want confirmation that a certain person has done something in git, you'll have to have them sign the commit in some fashion.
github is correcting in politely passing this off as a non-issue.