241–250 of 305 posts
Earlier quoted context omitted.
Doesn’t that mean you have to fix all the merge conflicts introduced by your commits on every rebase though?
Git has gotten pretty smart about that recently: once you resolve a conflict, if you get the same conflict again it automatically resolves it the same way. Works for both rebase and merge.
Earlier quoted context omitted.
>each commit nominally should work Except it can be the result of 10 squashed commits.
Which is the entire point of it. Why should I look at ten commits when I can look at one and get the same exact data? Why should I pollute my production history for what a is likely a bunch of debugging commits? The branch is a scratchpad, you should feel empowered within your own branch, rebase allows you to be lazy in the development cycle while presenting a nice clean set of changes at the end of it.
Without Squash, the main branch history becomes a timeline of your mental struggle.
With Squash, the main branch becomes a catalog of features delivered.
No body needs to take a trip on the struggle bus with me...
Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…
I will try to give Jujutsu a go based on your recommendation!
Then if you screw up, even several steps later when it's hard to un-rebase a portion, you just go back to the original. No need to dig through the ever-confusing reflog format, just use branches. For really gnarly ones, it also means you can early compare the two diffs to see if you missed anything.
Once you're fully happy with it, you can push that new one, or just go back to your original and `git reset --hard after-rebase-branch` to adopt the new history.
PSA: I’m not terrified of rebase, yet it’s good to know this: https://docs.github.com/en/get-started/using-git/about-git-r... > Warning - Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository. A similar warning is in Atlassian docs.
I also get tons of mileage out of This One Weird Trick: make a new branch first. Every single time it appears non-trivial, just abort and branch before continuing. Then if you screw up, even several steps later when it's hard to un-rebase a portion, you just go back to the original . No need to dig through the ever-confusing reflog format, just use branches. For really gnarly ones, it also means you can early compare…
Earlier quoted context omitted.
Squash merges are a hacky solution to the git bisect problem that was solved correctly by --first-parent 20 years ago. There are fully employed software developers working on important stuff that literally were never alive in a world where squash merges were needed. Don't erase history. Branch to a feature branch, develop in as many commits as you need, then merge to main, always creating a merge commit. Oftentimes,…
Using git history as documentation is hacky. A majority of feature branch commit messages aren't useful ("fix test case X", "fix typo", etc), especially when you are accepting external contributions. IF I wanted to use git history as a form of documentation (I don't. I want real documentation pages), I'd want the history curated into meaningful commits with descriptive commit messages, and squash merging is a great w…
I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…
I'm really sorry. Using bisect and log -S saved hours of code debugging