this post was submitted on 08 Nov 2023
84 points (85.6% liked)

Programming

17424 readers
27 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

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 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] knoland@kbin.social 15 points 1 year ago (2 children)

My favorite version of this is when the novice has followed someone's dodgy advice to set pull.rebase = true, then they pull a shared branch that they're collaborating on, into which their coworker has just merged origin/main. Instant Sorcerer's Apprentice-scale chaos!

Why are you doing that? Don't do that.

[–] QuadriLiteral@programming.dev 1 points 1 year ago* (last edited 1 year ago)

And anyway... it's trivial to fix. If you still have the commit ID of the tip of the branch before the pull, go back to that. If not, look it up in the reflog. If that's too much of a hassle, list the commits you only have locally, stash any changes, reset to the origin/the_branch and cherry-pick your commits again and/or apply the stash.

I really embraced git once I understood that whatever I did locally, it's most of the time relatively easy to recover from cock-ups. And it's really difficult to lose work from the moment you've added it to a (local) commit or stashed it.

I do understand that git is daunting however, and there is plenty where I think the defaults are bad. Too often I've seen merge commits where someone merged a the remote of a branch into the local copy of the same branch, or even this on main. And once this stuff gets pushed it's neigh impossible to go back.

[–] mr_satan@monyet.cc 0 points 1 year ago (1 children)

In my, rather short (5ish years profesionally), career I needed to rebase once. And it was due to some releasing fuck up, a branch had to be released earlier and hence needed to be rebased on another feature branch scheduled for release.

Otherwise, fetch » pull » merge, all day, every day.

[–] QuadriLiteral@programming.dev 5 points 1 year ago

I rebase almost daily. I (almost) never merge the main branch into a feature branch, always rebase. I don't see the point of polluting the history with this commit (assuming I'm the only dev on this branch). I also almost always do an interactive rebase before actually pushing a branch for the first time, in order to clean up commits. I mostly recreate my commits from scratch before pushing, but even then I sometimes forget to include a change in a commit I've just made so I then do an interactive rebase to fold fixup commits into the commits they should've been in.

I like merging for actually adding commits from a feature branch to main (or release or ...)