
More Git and GitHub Secrets - DanielRibeiro
http://zachholman.com/talk/more-git-and-github-secrets/
======
mattdeboard
Every git talk everywhere, everytime, should include "git rerere".
[http://git-scm.com/blog/2010/03/08/rerere.html](http://git-
scm.com/blog/2010/03/08/rerere.html)

Best time saver ever.

~~~
oneandoneis2
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
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.

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

------
bluetidepro
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
We released task lists earlier this year: [https://github.com/blog/1375-task-
lists-in-gfm-issues-pulls-...](https://github.com/blog/1375-task-lists-in-gfm-
issues-pulls-comments)

------
iamthebest
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
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

------
aroman
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
It says Keynote at the bottom of his blog post.

~~~
aroman
Hah, thanks for pointing that out!

------
oelmekki
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 ?

~~~
graphene
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.

~~~
sergiosgc
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.

~~~
skeletonjelly
Can't you generate a public key from a private one easily?

~~~
gbaygon
Yes:

    
    
      ssh-keygen -y -f private_key.pem > public_key.pub

~~~
emmelaich
Yes and no. It extracts the public key from the private key file. The
"private" key file includes both keys.

The public key file doesn't.

~~~
dlitz
> The "private" key file includes both keys.

It wouldn't need to, though. Given the private key (n,d), the public key is
probably (n,65537).

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

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

~~~
eroullit
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](https://gist.github.com/eroullit/1250603))

~~~
zeckalpha
If you use C-family languages?

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

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

