More Git and GitHub Secrets

http://zachholman.com/talk/more-git-and-github-secrets/

by DanielRibeiro • 13 years ago

263 38 13 years ago

zachholman.com

zeckalpha2• 13 years ago

git stripspace is neat. I'll have to add that as a hook.

zalew• 13 years ago

yeah, it's awesome. I had no idea this existed.

eroullit• 13 years ago

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)

zeckalpha2• 13 years ago

If you use C-family languages?

bluetidepro• 13 years ago

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.

jbarnette• 13 years ago

We released task lists earlier this year: https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-...

krallja• 13 years ago

git diff --cached is one I need to remember.

kzrdude• 13 years ago

`git diff --staged` is the same thing. Git did a very halfhearted move to the `stage` verb and then stalled.

silasb• 13 years ago

I have two aliases that I use all the time.

`gd`

and

`gdc`

I'm sure you can figure out what each of those means.

mattdeboard• 13 years ago

Every git talk everywhere, everytime, should include "git rerere". http://git-scm.com/blog/2010/03/08/rerere.html

Best time saver ever.

jedbrown• 13 years ago

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.

Anderkent2• 13 years ago

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).

oneandoneis2• 13 years ago

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.

maw• 13 years ago

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.

iamthebest• 13 years ago

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.

bru• 13 years ago

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_file

Timothee• 13 years ago

"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.

oelmekki2• 13 years ago

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 ?

graphene2• 13 years ago

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.

Anderkent2• 13 years ago

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.

sergiosgc• 13 years ago

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.

seniorsassycat• 13 years ago

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.

oelmekki2• 13 years ago

Ok, thank you both for clarification.

txutxu• 13 years ago

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.

inopinatus• 13 years ago

This is also the reason not to forward your ssh-agent (in my view, one of the most poorly considered features of ssh).

CalinBalauru• 13 years ago

I will love for this to get featured again on the main page when the video is available

aroman2• 13 years ago

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.

joeblau• 13 years ago

It says Keynote at the bottom of his blog post.

aroman2• 13 years ago

Hah, thanks for pointing that out!

platz• 13 years ago

It's a small detail, but I appreciate that he even identifies the typefaces used in the deck at the bottom of his post.

More Git and GitHub Secrets

Related Stories