In my cases I has to solve same code conflicts multiple times during a rebase, so I just don’t try them when hit with conflicts.
I fail to see the benefits of “clean” git history
In my cases I has to solve same code conflicts multiple times during a rebase, so I just don’t try them when hit with conflicts.
I fail to see the benefits of “clean” git history
I’m the opposite. I just let git take care of the stupid content. Why mess with the commit graph? Merging locally (instead of squashing) works better with merge requests because the graph clearly shows what changes went where.
I do some branch maintenance on my local branch (rebasing) until there are conflicts, but other than that I don’t see any benefit for messing with commit history.
Same… My usual strategy: rebase, if conflict abort and merge, if no conflict continue; merge always with explicit commits to master / main (no fucking squashing); keep task references in branch names and commit messages.
When Microsoft announced the sunset of Windows 10.
I was still in uni at that time. Started with Ubuntu, disliked snaps and moved to Pop. Stayed there for last 5-ish (?) years. It does what I want it to do, I don’t care about switching distros now.
Maybe I just haven’t been exposed to bad examples. Never had any issues with blame and merge commits.