I have taken to using the --force-with-lease flag instead of just --force. It gives some protection that the repo you are pushing to hasn’t been changed by someone else in the meantime, and you trash that work.
I really wish --force-with-lease was simply --force, and that this latter option was something like --force-for-reals. Saner defaults are always a good thing.
The thing that still trips me up about rebasing is that conflict diffs are reversed.
That is, when you pull or merge, you’re adding the remote content to your branch, so “ours” or “current” or “<<<<<<” is your own branch’s change, and “theirs” or “incoming” or “>>>>>>” is the remote branch’s change. But in a rebase, the operation temporarily checks out the remote branch and cherry picks your commits onto it, so your branch is “theirs” or “incoming” instead.
That terminology seems backwards and confuses me every time, unless I remember the implicit checkout. Even now I’m only about 80% sure of what I’ve written here.
This trips me up every time as well. If it’s just my own changes I’m conflicting with (like, if I’m preparing my commits before review, and are rearranging), then I generally abort and use squash + edit with rebase to handle it instead.
The fact that github PR workflows does not support git diff between force pushes is so mind bending to me. Their core staffs who contribute to git core uses rebase regularly.
Gitlab does retains diff between force pushes is a nice to have, but comes with a long term performance trade-off.
I’ve decided the reason I’ve never mastered rebase is because working with small reams on production and OSS projects there is little value in tidy history. For projects involving really large teams this is completely different.
Even if there are only 2-3 developers, being able to see the flow of changes going into mainline as discrete feature oriented chunks is immensely helpful when you’re going back through history trying to figure out exactly where something went wrong.
Honestly, I find a lot of use in a tidy history in all projects. Any time that I need to use git log -S, git bisect, git revert, it makes it way easier if the history is tidier. I do use these tools in my personal projects, because they’re v powerful for finding bugs.
I have taken to using the
--force-with-leaseflag instead of just--force. It gives some protection that the repo you are pushing to hasn’t been changed by someone else in the meantime, and you trash that work.See e.g. http://weiqingtoh.github.io/force-with-lease/
I really wish
--force-with-leasewas simply--force, and that this latter option was something like--force-for-reals. Saner defaults are always a good thing.Great tip! Thanks
Oh this is great! Thanks
I learned about this after overwriting a coworker’s commit. Excellent flag, should really be the default for -f
The thing that still trips me up about rebasing is that conflict diffs are reversed.
That is, when you pull or merge, you’re adding the remote content to your branch, so “ours” or “current” or “<<<<<<” is your own branch’s change, and “theirs” or “incoming” or “>>>>>>” is the remote branch’s change. But in a rebase, the operation temporarily checks out the remote branch and cherry picks your commits onto it, so your branch is “theirs” or “incoming” instead.
That terminology seems backwards and confuses me every time, unless I remember the implicit checkout. Even now I’m only about 80% sure of what I’ve written here.
Oh. So I wasn’t insane last Friday. Thank you. I couldn’t make heads or tails of what came from where resolving conflicts rebasing my changes. :)
This trips me up every time as well. If it’s just my own changes I’m conflicting with (like, if I’m preparing my commits before review, and are rearranging), then I generally abort and use squash + edit with rebase to handle it instead.
The fact that github PR workflows does not support git diff between force pushes is so mind bending to me. Their core staffs who contribute to git core uses rebase regularly.
Gitlab does retains diff between force pushes is a nice to have, but comes with a long term performance trade-off.
They’ve half-assed this feature now. On the message where it says you force pushed, if you click the text “force pushed,” it will give you a diff.
However, multiple force pushes will be collapsed into one message, and clicking on that link will only show you the latest force push diff.
Isn’t it weird that we have to do these sort of hoops to have basic workflows?
I’ve decided the reason I’ve never mastered rebase is because working with small reams on production and OSS projects there is little value in tidy history. For projects involving really large teams this is completely different.
I disagree.
Even if there are only 2-3 developers, being able to see the flow of changes going into mainline as discrete feature oriented chunks is immensely helpful when you’re going back through history trying to figure out exactly where something went wrong.
Honestly, I find a lot of use in a tidy history in all projects. Any time that I need to use
git log -S,git bisect,git revert, it makes it way easier if the history is tidier. I do use these tools in my personal projects, because they’re v powerful for finding bugs.