4 ms·
The problem with rebase is it creates a lot of friction when sharing with others. Even if a single dev has two checkouts, it can get confusing ("can I just pull
by osigurdson 2y ago
The problem with rebase is it creates a lot of friction when sharing with others. Even if a single dev has two checkouts, it can get confusing ("can I just pull the changes or do I need to reset the branch? - dammit what did I do again? I guess I'll have to review both checkouts history in detail"). Merge based git push / git pull in the other hand, have none of this, thus conceptually much simpler.
Furthermore, since pushes must necessarily overwrite (--force), you actually risk loosing work.
This is all fine and doable but you have to be "on the ball" / paying close attention all the time thus introducing higher cognitive load.
The bottom line is getting work done and making history look good are competing objectives to some extent. There are all kinds of reasons to commit code (I got something working, I want to share something, I need to try this on another machine, etc.). Thus, the only way for commits to appear logical / atomic is to review the current state and refactor it to a logical looking but artificial series of commits. I can't imagine such efforts being useful enough to actually do in most cases. Perhaps even a task better suited to AI.
In reality, the PR is the only commit that anyone cares about. Everything else is mostly just noise. Therefore it would be best if the PR was a first class concept in git vs something only available outside of it (i.e. github).
- klysm 2y agoAlways use --force-with-lease.
- rednafi 2y agoThis will only save you if you haven't taken a pull right before pushing your changes to the remote branch. I almost always do this: ``` git pull --rebase main ``` And then push the changes with `git push origin HEAD`. Pushing with `--force-with-rebase` won't save me from this. I usually never rebase a shared branch.
- rednafi 2y agoTwo rules of rebasing that I follow strictly: 1. Never rebase a shared branch 2. Never break rule 1
- rurban 2y agoAlways rebase and push --force. Devs who cannot pull --rebase or reset --hard to latest should quit their jobs, and stop whining.
- osigurdson 2y agoTrue Scotsman. Does it or does it not increase cognitive load?
- rurban 2y agoNo cognitive load. Just just magit and a set of git aliases
- osigurdson 2y agoWhat is your definition of a shared branch? Is it shared the moment you push it (assuming a github like workflow). Is it shared if you check it out on two separate machines just for yourself?
- rednafi 2y agoMy definition of a shared branch is the one where only one person is working. It can be your local branch and the same one after you push it to remote. It's still not shared in the sense that only 1 person is supposed to work on that branch. In this case, you can easily perform rebase and run `git push origin HEAD --force-with-lease` without causing any headache for anyone else.
- osigurdson 2y agoSay you have a checkout on Linux and one on Windows and need to do some bespoke development work on each. I personally would just do git push / pull to avoid any potential for lost work. Maybe after the work is done, I would refactor the commits and rebase them before pushing to the authoritative server (e.g. github, azure dev ops, etc.).