2
submitted 1 month ago by [email protected] to c/[email protected]
top 12 comments
sorted by: hot top controversial new old
[-] [email protected] 1 points 1 month ago* (last edited 1 month ago)

When I'm just locally iterating on stuff I'll usually do a git commit -m "WIP: Description of what I'm trying to do" and then git commit --amend to it. A bit more ergonomic than stashing if I want to switch branches imo. I can also go back to old versions if I want to through the reflog.

git commit --fixup some-commit is also great for if I discover things in the review for example. You can then do git rebase master --autosquash to flatten them into the commit they belong to and that way you don't have to bother with commit messages like "fixed typo". Doing fixups for small fixes is good because it allows you to keep your mr broken up into several commits without also leaving in a bunch of uninteresting history.

Can recommend checking out the --fixup section in the git documentation if you haven't heard about --fixup before.

[-] [email protected] 0 points 1 month ago

But shouldn't be. How hard is it to summarize your work in a few words? Even a bad description is more memorable than a hash.

[-] [email protected] 2 points 1 month ago

The post mentions that these are for commits in a merge request before squash. When they’re squashed a proper message is given.

[-] [email protected] 0 points 1 month ago

Also, squashing is a pretty bad practice as it is. I can understand that it may make sense sometimes, but most of the time if you don't commit every other character you input, you're better off leaving some history of how your code evolved and what changes were coming together

[-] [email protected] 1 points 1 month ago

I think squashing is great and I would never want to go back. It helps ensuring:

  • All commits in main have useful messages. No more “fix pipeline errors”, “fix MR comments”, etc.
  • Ensures pipeline has been successful with all commits in main. No need to guess which commits will build and won’t build.
  • Easy to revert commits.
  • Eliminates incompressible history because someone had a bad day with git.
  • Encourages frequent commits. No need to ensure all commits are perfect and good in their own right. Commit when you want to commit even if it’s incomplete work.

And IMO, if your work warrants multiple commits, then it probably also warrants multiple merge requests. Merge requests should be rather small to make it easier to review.

Edit: another good thing is that when we decide to release, we can easily look through the commit history for a change log. No more sifting through minor fixes commits.

[-] [email protected] -2 points 1 month ago

git rebase trumps all of the things you mentioned...

Anti Commercial-AI license

[-] [email protected] 0 points 1 month ago

Git rebase can be hard to understand for many. Not everyone has the blessing of being in a team of Git gurus.

[-] [email protected] -2 points 1 month ago

It's more about the tooling. IDEs make it really simple.

Also people get scared when they hear it because of utterances like yours. I'm dumb af. Git rebase for your use cases can be renamed to "git edit-history $fromCommit". Nothing special about it.

Anti Commercial-AI license

[-] [email protected] 0 points 1 month ago

Sure, but how much of that is justification and backpedaling?

If it's worth a commit, it's worth a description. "Address vulns" "fix config" "remove files". It doesn't take much. Even if it's just "more address vulns".

[-] [email protected] 0 points 1 month ago

Often I commit because I have to jump to another branch, so I want to save my progress. This means I can be in the middle of something, so I write a trash message.

All those messages will disappear anyway after the merge request, because we use a squash policy. I can spend more time thinking of a more proper commit message when writing the merge request.

[-] [email protected] 1 points 1 month ago

git worktree could become your new friend then :)

[-] [email protected] 1 points 1 month ago

How about WIP: <description of what you wanted but did not achieve yet>?

this post was submitted on 19 Jul 2024
2 points (100.0% liked)

Git

2814 readers
3 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS