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.
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).
"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.
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.
Zach'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.
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.
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.
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.
No. 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.
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)
Best time saver ever.