6 ms·
More Git and GitHub Secrets
- zeckalpha 13y agogit stripspace is neat. I'll have to add that as a hook.
- zalew 13y agoyeah, it's awesome. I had no idea this existed.
- eroullit 13y agogit 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 13y agoIf you use C-family languages?
- bluetidepro 13y agoGreat 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 13y agoWe released task lists earlier this year: https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-...
- krallja 13y agogit diff --cached is one I need to remember.
- mattdeboard 13y agoEvery 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.
- jedbrown 13y agoIndeed, 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.
- Anderkent 13y agoTo 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 13y agoI 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 13y agoNod. 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 13y agoQuick 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 13y agoFixed 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 13y 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.
- oelmekki 13y agoA 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 13y agoNo, 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.
- Anderkent 13y 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.
- graphene 13y agoYes, you're absolutely right; it seems it's too late to edit my original post though...
- sergiosgc 13y agoUsually, 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 13y agoCan't you generate a public key from a private one easily?
- gbaygon 13y ago
- CalinBalauru 13y agoI will love for this to get featured again on the main page when the video is available
- aroman 13y agoZach'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.