Programming

27789 readers

359 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

The git history command deserves more attention (lalitm.com)

submitted 3 days ago by HaraldvonBlauzahn@feddit.org to c/programming@programming.dev

13 comments fedilink hide all child comments

Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze.

jj, an alternative to git, gets discussed a lot these days (1, 2, 3, 4) and is often pitched as a solution. While I’m very sold on the problems jj is trying to solve, the way it solves them hasn’t quite hit home with me. Every 3 months, for the last 1.5 years, I try it out for a few days, really trying to make it part of my workflow but eventually I give up and go back to git.

That’s where git history comes in.

you are viewing a single comment's thread
view the rest of the comments

[–] JackbyDev@programming.dev 1 points 22 hours ago

I don't know, the number of times I've needed to make two small changes in parallel is certainly non zero. The amount of times I've been mostly done with a feature and began a new one before a PR was totally merged is certainly non zero. Even then, some changes can make more sense if broken it into multiple commits (a moot point at most teams since squash and rebase seems to be the norm). You can keep a linear history and still have multiple commits in a branch, just commit (har har) to reading instead of merging.

Regardless, doing commit fixups and rewords are not necessarily rare. These commands are still super useful. Bear in mind that just because something isn't useful to your workflow, git is used by many different people with many different types of workflows.