> HEAD^^^^^^^
Dude! Learn the tilde notation
Git rebase, what can go wrong
171–180 of 404 posts
Re: Git rebase, what can go wrong
#172I love rebase (I'm a tip-of-master-only person, no merges ever, squash all your commits with `rebase -i` before pushing and write one good commit message for the group). But there's one really, really irritating thing about them: You should not be able to use `--amend` during a rebase. For me editing all my changes onto the commit I'm working on with `git commit -a --amend` (or as I've aliased it, `gcaa`) is automati…
I’m curious how this workflow differs from `git merge --squash`.
I dunno, I've literally never used merge ever since realizing what it does to the commit history.
Re: Git rebase, what can go wrong
#173Earlier quoted context omitted.
A bunch of wip wip2 wip3 commits don't add any value, and make the log harder to read. But if you break a bigger PR down into "added feature x", "tests for feature x", "refactored y to support x" -- the commits are easier to read and provide valuable "why" history when you're trying to figure out what happened two years later.
That's more about the contents of the merged commits than anything else. Modifying the commit message(s) fixes that, as long as that's what the commits actually did. Aside from that, how are "a fix for a bug" style commits not "clean"? If merge 123 into master contains a bug that is fixed in a future merge 1234, it doesn't seem "dirty" to me; quite the opposite actually, as it tracks what actually happened. Now, "wip…
Modifying commit messages is rewriting history, right?
> “wip” style commits shouldn’t be on whatever branch everyone is working on
Agreed! We aren’t talking about rewriting shared branch history, we are talking about removing the “wip” commits made hastily and locally before pushing them. Sounds like we agree!
Re: Git rebase, what can go wrong
#174I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…
Squash merges cut down the noise considerably.
> Squash merges cut down the noise considerably.
They do but they have their own issues. e.g. having to delete local branches using git branch -D instead of git branch -d and getting the protection from deleting unmerged work.
I still agree that on balance annoyances like that might still be worth putting up with for larger teams with mixed skill levels.
Re: Git rebase, what can go wrong
#175Earlier quoted context omitted.
The point of a clean git history is not to have a clean git history. The point is to make it possible to debug later, via bisect, or show, or even just a diff. The point is to make the workspace clean for the next guy. Instead of letting it go, maybe we should have more discipline and organization in our lives and not less.
Did you notice, though, that rebase advocates use very "emotive" terminology when talking about git history? Like it's a subject they care about? Seems awfully touchy feely.
I don't know if "emotive" is the right word, because to me this whole discussion is like trying to tell someone to be less sloppy because they make a mess when eating at their desk, knowing that the custodians will clean up after them.
Re: Git rebase, what can go wrong
#176Responses would make more sense if people included:
- if they have done any cherry-picking - if they have done any backporting - if they have reverted any commit that made it to main - if they have ever used bi-sect
I think rebase is harder to learn than merge, but once you get used to it, it lets you have history that is easier to debug, and use without extra effort
Re: Git rebase, what can go wrong
#177I hope Julia keeps writing about git, because I'm sure it will teach me something!
I'm still searching for a way to manage long-lived Postgres submissions, the most challenging git scenario I've encountered. Julia's post finally got me to brain-dump my current process, something I've meant to write down for a while now:
https://illuminatedcomputing.com/posts/2023/11/git-for-postg...
This link could almost be an "Ask HN": if any of you have suggestions to improve my workflow, I'm all ears. (I asked around a bit last May at PGCon, but didn't get any concrete advice there. Maybe it's too complicated for a hallway off-the-cuff discussion.)
Re: Git rebase, what can go wrong
#178Earlier quoted context omitted.
> destroying Commit information just to keep the graph tidy is a bad idea in my opinion The commit information I see when telling teams to squash their branches on merge is not valuable. * "fixing whitespace" * "incorporate review comments" * "fix broken test" * "fix other broken test" (note, the broken tests were broken by the changes in the PR) As soon as that PR is merged those commits are worthless. And there are…
> * "fixing whitespace" * "incorporate review comments" * "fix broken test" * "fix other broken test" Things like this should not be standalone commits though, they should be incorporated into the previous branch by amending the original work. It takes some effort to have a useful git history, it does not just happen on its own.
I rather strongly disagree here.
Having whitespaces mucks up commit, causing you to lose focus of what's actually important.
I have `git blame` aliased to `git blame -w` which ignores whitespace-only changes.
You can also reblame when you come across this formatting commits.
Re: Git rebase, what can go wrong
#179Earlier quoted context omitted.
Squash merges cut down the noise considerably.
I actually hate squash merge because of all the noise it adds. Sure, the commit graph looks nicer, but it come with a terrible loss of information when doing git blame. I'm a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I'm working on, and I die a little bit each time I try to understand what changes were related to a line wh…
Git blame confuses people even without squash merges.
I've seen people forget to go back more than one commit and then blame the person who last indented a file instead of going back to the commit that actually wrote the code many times.
Re: Git rebase, what can go wrong
#180I’ve never understood the tradeoff of rebasing, squashing or otherwise “keeping a clean history”. It always seemed like tons of sometimes highly error prone work (sometimes you can wipe out a colleague’s work with it! Wtf!), for almost no gain (why does it matter that the git history is “clean”?).
It matters because when I: * use filtering commands like "git log -S" * press the "annotate" button in my IDE and can see which commit introduced each line * run "git bisect" * use "tig" to drill down through the history of a file (shortcut "," is "move to commit preceding current line's blame commit") ...every step of the way, I get a meaningful description of why a change was made and what other diffs were necessar…
> * press the "annotate" button in my IDE and can see which commit introduced each line
In PyCharm, I can see which commit introduced each line, regardless of branching. Same with drilling down through a files history. Is this an IDE limitation you're seeing?
> every step of the way, I get a meaningful description of why
Isn't this more about commit messages, than anything else?