1y ago

Manager: This task only takes 30 minutes. Why did it take you the whole day?

100 comments

Every time I commit I have to look through git diff, figure out what the hell I actually did, come up with something intelligent to say about jt, possibly split the commit into multiple commits if I changed multiple things, do some shuffling with git reset and git add...
For some reason all my personal projects are all like 4K SLoC with 50 total commits, all of which include apologies for not doing more smaller commits
- There's a bigger issue than your commit message if you don't even know what you just coded and are committing.
  
  You see, sometimes I code something, go to bed before finishing it, come back, decide not to commit because then I'd have to think of a commit message and I just want to code, start working on an unrelated feature, do that for a couple days, get distracted by life stuff and put the project down for a few weeks/months, rinse and repeat, and then I finally get around to writing a commit message because I'm about to start a huge change and I want a restore point and I'm like. Okay, it's been like 3 months since my last commit, I'm pretty sure my code can now do something it couldn't 3 months ago but come on, I can't even remember what I had for lunch last Thursday
  I'm well aware this is terrible practice but I don't know how to stop doing it
  
  I just get too excited about actually implementing/fixing something (random things that I see along the way) more than commit ceremony (nobody will care about it in my project anyway other than one random guy who gave the repo a star)
  
  it means you commit too infrequently. your commit messages should be able to describe what u just did within 10 words.
- ^psst, ^git ^add ^-p
  
  Remind me what -p does.
  Edit: never mind - I see it mentioned below.
- I spend much time splitting them up inside visual studio by file and individual lines changed to try and separate my many simultaneous changes into several somewhat usable commits. If I was stupid enough to make some big refactor at the same time I might just have to throw in the towel... It's really painful after a few weeks to try and pick up the pieces of what I was doing but never commited too lol.

Just use What The Commit.
You can also create a git alias:
git config --global alias.yolo '!git add -A && git commit -m "$(curl --silent --fail https://whatthecommit.com/index.txt)"'
Now you can just type 'git yolo' to create a commit!
- "Make Sure You Are Square With Your God Before Trying To Merge This"
- Full send.
- Well such an informative reply! Thanks mate 👍
- "Chuck Norris Emailed Me This Patch... I'm Not Going To Question It"
  
  My first script ever was written in lua for a world of warcraft macro to spit out chuck norris one liners. People in the barrens hated me.
- Thanks for that, I've been laughing like a little kid:
  "hoo boy"
  "lol"
  "Become a programmer, they said. It'll be fun, they said."
  I can feel those so well! :')
- Well that's about half my commit messages that are going to be nonsense on weekends projects, now. Thank you!

Psst,
git add -p
- What does this?
  
  "patch mode" - Patch mode allows you to stage parts of a changed file, instead of the entire file. This allows you to make concise, well-crafted commits that make for an easier to read history.
- Better yet, git commit -p
  
  uuuuuuuu. and you could do -m to describe the commit.
  next they'll add --push/-P.
  perhaps add -r for fetch/rebase then commit.
  one command to rule them all! 😈

git commit -m “changed somethings “
git push origin master
- You forgot this --force flag.
  
  I'm too lazy, I use -f
- Do you always have to do origin master? I've seen it where sometimes just git push works and other times not.
  
  I was being more evil than that, saying that if one is gonna push direct to main, might as well maximize the possible damage to everyone else's branch.
  
  where it Just Works, the branch is set up to track a remote branch
  https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches
  
  uh in any actual company you almost never push to origin master. so I think it's a joke.
  
  https://git-scm.com/docs/git-push#Documentation/git-push.txt-pushautoSetupRemote
  
  push origin your/branch
  Pushes, you guessed it, your/branch!
  Head is usually your checked out working branch if you're not in a headless state, right?
  
  That’s part of the joke, I think. If it’s a repo more than just you use, you would almost never push directly to the main branch.
  
  I think it depends what branch your local version of the repo is set to. If you're already in master then it'll push there, if you're in a testing branch then you can push it straight to master instead by telling it to

I’m using Copilot for it right now. It works on half of the cases.
- That's about 300% better than my average!

For me, it was my boss gave me a programming task which he knew would take hours or a day or two... and then 15 minutes later tells me to "switch focus" and do a menial task that any of my five coworkers could do 🤦‍♂️

The usual reason would be "because coworkers"

Forward three hours, me using thesaurus.com to try fit the whole gist of my change into the first line.

That's in any bloody workplace! Especially if there is o synergy between different teams.

"stuff"
- "Commit"

Oh god I feel so called out. I wish I paid more attention to my commit messages but I’m usually too busy fixing the directory structure and refactoring. Sigh.
- My company collapses into a single commit at merge so idgaf what the commit message is anymore. Though I would prefer not collapsing them.
  
  Master should just have the feature description commits, not the hundred commits it took to get there after refactoring the code for the 3rd time and pulling changes from master since it's taken so long to get done.
  
  Yeah I worked at a place like that, but it made sense because we were also expected to keep PRs small, so a good commit message for several squashed ones was perfectly fine.
  
  I prefer that approach. We work with smaller tasks, so it makea more sense, plus it helps keep the master clean and if you want a more detailed view of the specific commits, you just have to click on the link to the PR. It's a better way to organise it IMO

do git commit -v and then just summarize the diff you have in your editor in a human readable form.
- Don't just summarize the content though, summarize the rationale or how things connect. I can read your diff myself to see what changed, I want to know the logical connections, the reason you did X and not Y, etc.
  Or just say "stuff" and provide that context in the PR description separately, no need to overdo the commit log on a feature branch if you're using squash merges from your PR.
  
  P1000x this.
  I can read a diff.
  I need to know why.
  No, a code comment isn't good enough, it's out of date after the next commit.

Me trying to find ways around using the word "and" in the commit message.
- git commit -m "directory_x:file_i.so: did x, y, and z; directory_x:file_ii.so: fixed t"

You should not use -m, you should write commit body!
- Why? My coworkers are barely literate and won't read anything with more than 4 or 5 words, writing a commit body would be a waste of time.
- Nah, most commits don't need a body

[conventional commits] (https://www.conventionalcommits.org/en/v1.0.0/) will save you.
or maybe commitizen if you'd like not to write them by hand.
and maybe commit and tag version, which will create changelogs for you of you follow semver

"blah"

100 comments