More Git and GitHub Secrets(zachholman.com)
zachholman.com
More Git and GitHub Secrets
http://zachholman.com/talk/more-git-and-github-secrets/
38 comments
Indeed, but rerere is tricky to explain because it goes hand-in-hand with a workflow that integrates topic branches via an integration branch that is not permanent ('next' in git.git). Despite its numerous unique benefits, it usually takes people a while to understand this workflow.
I dislike rerere because it's very difficult to get it to stop remembering your mistakes. I've always found it causes more hassle than it solves.
Nod. I use it and appreciate it, but I'm not entirely satisfied with it either for just this reason. It certainly isn't the last word in its space.
To verify that I get it right, the advantage is that with rerere you can merge master into your topic branch, fix all conflicts at once, then have rerere reuse those fixes when you rebase your branch onto master?
I don't suppose it's smart enough to work even if your branch has changed a conflicting file multiple times (i.e. the conflict you see in `git merge` is different than the first conflict you get in rebase, for that particular file).
I don't suppose it's smart enough to work even if your branch has changed a conflicting file multiple times (i.e. the conflict you see in `git merge` is different than the first conflict you get in rebase, for that particular file).
"GitHub stores all pull requests in your repository […] even if the fork is deleted"
That's great to know! I have a few forks that are there only because I wanted to offer a tiny change to the doc or the website, etc. but I thought I'd have to keep them around until it was merged. (I can certainly leave them there, but it leaves a big mess of mostly untouched forks)
edit: my git tip will be "git stash --keep-index". This stashes only the stuff that you haven't staged. I've been using it when I want to keep unrelated changes out of the build process before committing. Or you can run that, and then "git stash" to have two (or more) separate stashes from your current state.
That's great to know! I have a few forks that are there only because I wanted to offer a tiny change to the doc or the website, etc. but I thought I'd have to keep them around until it was merged. (I can certainly leave them there, but it leaves a big mess of mostly untouched forks)
edit: my git tip will be "git stash --keep-index". This stashes only the stuff that you haven't staged. I've been using it when I want to keep unrelated changes out of the build process before committing. Or you can run that, and then "git stash" to have two (or more) separate stashes from your current state.
Great article full of awesome tips/tricks!
I didn't realize you could do check-box style to-do markers inside of messages for issues and pulls (- [ ] Task 1). I'm not sure how long this has been a feature, but this is fantastic to finally know about for sub-tasks inside of issues. I always had a painful time trying to break those up, and keep them grouped somehow via milestones, labels, etc.
I didn't realize you could do check-box style to-do markers inside of messages for issues and pulls (- [ ] Task 1). I'm not sure how long this has been a feature, but this is fantastic to finally know about for sub-tasks inside of issues. I always had a painful time trying to break those up, and keep them grouped somehow via milestones, labels, etc.
We released task lists earlier this year: https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-...
Quick recap of the git commands shown in the presentation:
git merge master -s <strategy> git merge master -s recursive -Xpatience git merge master -s octopus git merge master -s ours git diff stash{0} git --no-pager diff git stripspace < file git diff --check git diff --cached git merge --abort git merge -m "message" git merge --no-commit git status --ignored git update-index --assume-unchanged path_to_file git update-index --no-assume-unchanged path_to_file
Also, keep the commit message summary to 50 characters or less and wrap the long description at 72 characters.
git merge master -s <strategy> git merge master -s recursive -Xpatience git merge master -s octopus git merge master -s ours git diff stash{0} git --no-pager diff git stripspace < file git diff --check git diff --cached git merge --abort git merge -m "message" git merge --no-commit git status --ignored git update-index --assume-unchanged path_to_file git update-index --no-assume-unchanged path_to_file
Also, keep the commit message summary to 50 characters or less and wrap the long description at 72 characters.
Fixed indentation:
git merge master -s <strategy>
git merge master -s recursive -Xpatience
git merge master -s octopus
git merge master -s ours
git diff stash{0}
git --no-pager diff
git stripspace < file
git diff --check
git diff --cached
git merge --abort
git merge -m "message"
git merge --no-commit
git status --ignored
git update-index --assume-unchanged path_to_file
git update-index --no-assume-unchanged path_to_fileZach's talks are always so enjoyable and well put together. I wonder what he uses to build his slide decks -- he's certainly developed a very strong and unique visual style for himself.
A load of nice tricks, thanks.
I'm a bit concerned about the public keys public url. Ok, it's just public keys, so it must be safe, but I wonder : is it safe like it's "safe" publishing a login without a password ? In other word, doesn't knowing public key make easier to break private one ?
I'm a bit concerned about the public keys public url. Ok, it's just public keys, so it must be safe, but I wonder : is it safe like it's "safe" publishing a login without a password ? In other word, doesn't knowing public key make easier to break private one ?
Publishing a public key does not make cracking they private key easier. I guess if I got access to someone elses private key but I didn't know whose it was I could use the published keys to identify who the private key belongs to.
Ok, thank you both for clarification.
No, that's the whole point of public key cryptography; that the private key cannot feasibly be used to derive the public key, but the other way around is trivial.
>the private key cannot feasibly be used to derive the public key, but the other way around is trivial
I assume you meant to say that the private key cannot feasibly be derived from the public key, but the other way around is trivial.
I assume you meant to say that the private key cannot feasibly be derived from the public key, but the other way around is trivial.
Yes, you're absolutely right; it seems it's too late to edit my original post though...
Usually, the keys are entirely symmetrical. You just name one public and the other private. It's difficult to generate one from the other. The easy task is generating both at the same time.
> Usually, the keys are entirely symmetrical. You just name one public and the other private.
Nice try, General Alexander. :P
In DSA, the public key is (p,q,g,y) and the private key is (p,q,g,x). The public "y" is computed directly from the private key using the formula: y = g^x mod p. Thus, anyone who has the private key can compute the public key.
In RSA, the public key is (n,e) and the private key is (n,d). They're not interchangeable because of two speedups that we use:
1. Small public exponents. Most of the time, e is either 65537, 5, or 3. This speeds up encryption and signature verification, but also means you can trivially guess the public key.
2. CRT exponentiation. The private key is actually (n,d,p), where p is one of the prime factors of n. This speeds up decryption and signature verification, but recall that the security of RSA is based upon the difficulty of factoring n.
Nice try, General Alexander. :P
In DSA, the public key is (p,q,g,y) and the private key is (p,q,g,x). The public "y" is computed directly from the private key using the formula: y = g^x mod p. Thus, anyone who has the private key can compute the public key.
In RSA, the public key is (n,e) and the private key is (n,d). They're not interchangeable because of two speedups that we use:
1. Small public exponents. Most of the time, e is either 65537, 5, or 3. This speeds up encryption and signature verification, but also means you can trivially guess the public key.
2. CRT exponentiation. The private key is actually (n,d,p), where p is one of the prime factors of n. This speeds up decryption and signature verification, but recall that the security of RSA is based upon the difficulty of factoring n.
The private key is normally stored in a file containing both the private and public key.
Can't you generate a public key from a private one easily?
Yes:
ssh-keygen -y -f private_key.pem > public_key.pubNo. But it eases "man in the middle" attacks (someone impersonating the host you think you're connecting to, with that key).
Still, if someone puts your pub key in an authorized_keys of a malicious host, and then manipulates your DNS or ARP to conduct you to such host, you should get some SSH warnings about the host fingerprint, etc.
And still, if you're using a dedicated key, the only possible attack could be to make you commit your repo changes, to the malicious machine instead of to github.
Still, if someone puts your pub key in an authorized_keys of a malicious host, and then manipulates your DNS or ARP to conduct you to such host, you should get some SSH warnings about the host fingerprint, etc.
And still, if you're using a dedicated key, the only possible attack could be to make you commit your repo changes, to the malicious machine instead of to github.
This is also the reason not to forward your ssh-agent (in my view, one of the most poorly considered features of ssh).
If agent-forwarding wasn't implemented, more people would just copy their private keys to several machines.
At least when you use agent forwarding, your key is only exposed while you're actually connected to the machine.
At least when you use agent forwarding, your key is only exposed while you're actually connected to the machine.
I will love for this to get featured again on the main page when the video is available
git stripspace is neat. I'll have to add that as a hook.
git stripspace is a plus but if you are already considering to add a pre-commit hook, you could directly use 'indent'.
It trims those pesky whitespaces and indent your code automatically the way you see fit. (e.g: https://gist.github.com/eroullit/1250603)
If you use C-family languages?
yeah, it's awesome. I had no idea this existed.
Best time saver ever.