really appreciated everyone's suggestions on the previous thread! https://social.jvns.ca/@b0rk/112276852440106066
I only included things that I actually do in the cheat sheet (with a couple of exceptions like `git push -u`, which I only don't use because I have `push.autoSetupRemote true` configured) but there are a lot of other useful-looking tips in that thread that I don't personally use
Attached: 1 image working on a draft of a git cheat sheet, what's missing? most interested in relatively "basic" things in git that you always forget how to do. Right now I think the push/pull section is by far the weakest
@b0rk It's the same for me.
Even moreso that I have a convenient alias 'co' for it (and 'ci' for commit), and I would need to figure out similarly short aliases for switch and restore (sw and rs maybe?)
@b0rk I use git switch -C mybranch to automatically switch to the branch and reset it so that it's current. But when I want to reset a file back to what's in the repo, git checkout -- /path/to/file.
Guess I only made it halfway to the less overloaded commands 😂
@dade
That's the opposite of what I do. I use restore because git warned me to do so when I used the usual checkout. However creating or changing braches I still do with checkout
When ever I have to push or pull I do that with remote and branch. I stopped using git push -u, as it made it too easy for me to keep pushing to wrong branches, like main in stead of feature or stupid stuff like that.
@b0rk
@b0rk I learnt about git switch from that previous thread!
I’ve adopted it myself now, because if I’m ever working with a fit newby, it’s going to be much easier to explain.
Also I feel that if git can improve, then so can I!
@b0rk Great work.
Down the road, I hope to find a git glossary that explains terms like "stage", "rebase", "tracking", and being "in" a branch.
git commit -m "subject line of message" --edit. When my ADHD is being particularly obnoxious I'm fairly likely to lose track of what I was working on and in which window if I'm interrupted, and when I find it again it's nice to have it tell me what I was supposed to be writing a commit message about.@b0rk maybe it's just me, but somehow I missed a short mention of "git diff" or a pointer to the "diff staged/unstaged changes" section in "know where you are" (or maybe in "prepare to commit"?), as that will show you what you are about to commit – which is usually what I really want to do to prevent doing something stupid. But as I said, maybe that's just me.
[Edit: or maybe move the "diff staged/unstaged changes" between "know where you are" and "prepare to commit"?]
@b0rk I started looking for this poster on your website, and at least I found the bingo card.
@b0rk Sorry if this is already covered and I'm being obtuse, but if there a link to a text version of this somewhere? (I'm only asking because it seems useful for accessibility.)
Another slightly weird but related question: This seems useful and I'd like to post it somewhere at work. Other than crediting you by name, is there other information that should accompany it (a link, a license, or anything)? (And obviously if you object to reposting please say so.)
@b0rk no way! I just recorded a git intro for some friends and will send them this.
Here’s my feeble attempt at being nearly as useful as your zines are! https://youtu.be/3B7qxN48hro?si=7IGYCw_sPvE6yN0Z
really appreciated everyone's suggestions on the previous thread! https://social.jvns.ca/@b0rk/112276852440106066 I only included things that I actually do in the cheat sheet (with a couple of exceptions like `git push -u`, which I only don't use because I have `push.autoSetupRemote true` configured) but there are a lot of other useful-looking tips in that thread that I don't personally use
@b0rk $ git branch --sort=-commiterdate
fatal: unknown field name: commiterdate
$ git branch --sort=commiterdate
fatal: unknown field name: commiterdate
Hmm, something is wrong.