 Something I learned in my ~3rd year of using git that has saved my ass many times: `git commit -am [commit message]` should be avoided. You inevitably end up auto-adding files you shouldn't, and the CLI encourages short commit messages. Significantly better to do `git commit -v -a`. This pulls up your default editor and shows you the diff of the changes you are about to commit. You can see if any unwanted files/changes are about to be committed, and easily enter a verbose description. 27 comments | Expand all CWs
@darius this is kinda why i use just -a for commits which i'm confident are simple and git-cola for bigger projects @darius i had to use `git add -p -i` today because i made a headless persistent container for something and i think i prefer a GUI still
[DATA EXPUNGED]
 @darius this is one of the main things I try to communicate to junior devs: write verbose git commits! and make them a clean discrete idea as much as possible. all code is about communication and the commit message is a handy tool to figure out wtf the code is on about. I didn’t know about the ability to see the diff while writing! gonna update my alias @christa Yes! I emphasize that doing this writes 90% of your pull request for you ahead of time, and it does so while your brain is still inside the specific task of coding so you are in the best place to explain what you were doing and why. The PR itself then just becomes a place to contextualize the commit(s) within the larger feature you are PR'ing. @darius my favorite guide to writing git commit messages: https://chris.beams.io/posts/git-commit/ @stelepami I've never seen this before, this is great! It's exactly how I was taught to write commits @darius It's my favorite. It probably bugged me too much at my last job when the norm was just to write everything On the first line instead of using a header statement. @darius I decided it was not worth fighting for. They also preferred merging instead of rebasing; I tried to convert people there but it wasnt intuitive for the folks who preferred to use the Intellij plusin to the command line. Eh. Contract's over. @stelepami I think I would probably not try to convert people to rebasing while on a contract. Good commit messages are something even a beginner on day 1 of using git can do, and there's not really a failure state that can't be undone with --amend. Meanwhile, merge vs rebase is a pretty technical topic that can have unsafe failure states. @darius There was potential to convert to full time which didn't pan out, but I was thinking long term.  @darius we (speaking on behalf of all of the practitioners of technologikal arts) have an unhealthy relationship with being terse to avoid triggering each others' "tl;dr" responses. I would like to propose we'd probably be much better off working to eliminate the "tl;dr" response by replacing it with a more mindful "nl;gr" response - "nicely long; great read!" - rather than becoming more and more terse.  @redoak huh.. when I do git commit -a, it does not include untracked files. I'm on git v2.25.1  @darius Yeah the explicitness of which chunks i'm managing at any given moment is what I like most about magit (plus the ease of  @darius there's even a ZMQ standard that, along with other things, documents extended commit messages. @darius enjoyed your "make a person", btw!  @darius great tip! I’m personally a fan of splitting adding and committing into two steps:  @darius Well, dang, it's probably... [counting on fingers] over four years since I started using git, and now you have just taught me about commit's -v flag! Awesome. Most of the time I commit something, I have a 'git diff --staged' running in an alternate tmux pane. I'll have to try this out. |
Gregory's Server
@darius mmmmm -v sounds fun