6 ms·

I'll add what should be obvious to any seasoned git user: rebase is only possible for "private" commits. If the commits were published, then merge is the only s

I'll add what should be obvious to any seasoned git user: rebase is only possible for "private" commits. If the commits were published, then merge is the only solution, because otherwise with a rebase you will "change (git) history" and break people's repos that have yours as upstream. I recommend reading this 2008 exchange between top Linux developers learning to use git, and Torvalds's... characteristic language when talking about rebasing a "public" repo: https://www.yarchive.net/comp/linux/git_rebase.html https://www.yarchive.net/comp/linux/git_rebase.html (I'm putting "private" and "public" in quotes because they're really on a spectrum)

ruraljuror 2y ago
I like your point. The exception is if the project you work on is itself downstream, in which case maintainers will rebase those “published” commits, probably employing the same technique they use to keep their local development branches up-to-date with the downstream project.
MrDarcy 2y ago
In practice it’s fine to rebase and force push to your own published branch, even when it’s an open PR. Just mark it draft or otherwise communicate when it’s no longer a moving target.
- singpolyma3 2y ago
  Especially when it's an open PR. That's effectively essential in order to, say, address feedback
  - spankalee 2y ago
    I try not to rebase and force push for branches under active review though. It makes it much harder for the reviewer to see the changes that have happened since they last reviewed.
    - argulane 2y ago
      That's only a problem when using GitHub. GitLab and Gerrit correctly version such force push PR updates and provide a nice view of what has changed.
    - everybodyknows 2y ago
      I version-number PR branches for upstreams on GitHub. If my branch 'for-upstream-13.0' does not apply cleanly on top of upstream 'main', I sync my fork's 'main' to upstream in GitHub's Web GUI, fetch to my desktop, and build a new 'for-upstream-13.1' on top, with the help of git-cherry-pick. Might need a new PR. All history is preserved, both on GH and locally.
PaulDavisThe1st 2y ago
If you work on a branch also worked on by others, then yes, rebase is "only" possible on private commits. But if you work on a feature branch, you can publish that branch as long as everybody else understands that it is yours and nobody should push to it. Then you can safely git push --force to the feature branch so that others can (a) see what you're up to (b) test the results. When you're done, you can do a final (or only) rebase against the target branch then merge to that branch.
- smcameron 2y ago
  > Then you can safely git push --force What I hate about this workflow is it teaches you to git push --force. Then one day, you're in the wrong window and you accidentally git push --force on master. Much prefer a workflow where you never git push --force
  - necessary 2y ago
    Git hosting platforms generally have controls that allow you to prohibit force pushes on protected branches (i.e. master)
    - The_Colonel 2y ago
      This doesn't fix the problem since you still can do a lot of damage doing that on a (perhaps wrong) feature branch.
      - SOLAR_FIELDS 2y ago
        It certainly diminishes it significantly. Very few people are usually collaborating on the same branch together that isn’t the main branch in most orgs. So the chances of you destroying yours or someone else’s work that way is pretty low. You can also branch protect any arbitrary branch, at least on GitHub, though I’ve never been in an org that protects branches other than the main one, besides an org that used release branches. I’ve also never seen someone clobber someone else’s feature branch, though it probably does happen. Much more often people are accidentally clobbering their own branches. The ability to rewrite history on feature branches is powerful in a good way and slots right into the way Git is philosophically designed. I would probably not be interested in removing that feature to prevent the rare case that someone footguns themselves or someone else
forrestthewoods 2y ago
> rebase is only possible for "private" commits. This is false. Well, it can be false. Git sucks and makes it harder then it needs to be. It’s relatively easy to have multiple people working on a feature branch that is continuously rebased. Meta’s Mercurial-like VCS system automagically stores 100% of commits in the cloud. Feature branches are anonymous rather than named. It’s all just a tree of commit hashes. Having multiple people work on one “branch” requires some basic communication as to what is considered “tip”. But since it’s all anonymous there’s no issues with different people incrementing a named branch to different commits. Honestly it’s pretty simple and easy. Git makes it harder than it actually is.
- rmgk 2y ago
  As far as I can tell, what is really meant by “rebase is only possible for "private" commits.” is that for public commits, rebasing would require to coordinate with everyone interested in that branch. This seems to be very similar to what you say with “requires some basic communication as to what is considered ‘tip’” Requiring coordination (or a constrained model of allowed changes) when modifying things (such as what the tip/branch points to) is a general principle unrelated to git and applies to every workflow. That said, I do understand that Meta’s centralized tool is more useful for your usecase.
  - forrestthewoods 2y ago
    > I do understand that Meta’s centralized tool is more useful for your usecase. One of my chief Git complaints is that 99.9% of projects are de facto centralized on GitHub. Genuinely decentralized projects are vanishingly rare. The way Git auto-advances branch tags causes a lot of pain. Having lots of people commit to a shared feature branch that has lots of rebasing is quite easy when the “tip” is infrequently updated. Each person thinking they can declare the new tip with every commit is the source of pain.
    - rmgk 2y ago
      Again, I see where you are coming from, and I do agree that a lot of discussion about Git (and it’s workflow) is really about GitHub (and it’s workflow). But even when using GitHub as the hosting service, every time you work on a local branch (this includes main/master) you are working on something purely local that will not conflict with what anyone else is doing. It’s only by pushing/pulling that tracking branches are automatically updated, which seems to correspond to the operation that you would refer to as updating tip. As the rest of the discussion is this topic seems to indication, people do work on these “private” branches a lot, and do rebase/modify them freely to create a history as they like before publishing that history (at which point, you would require coordination with everyone who saw that to change it again). As far as I can tell, what the Meta tooling seems to offer is that you can see the “kinda private” commits of other people, if I understand correctly. That does sound indeed useful, but also out of scope for Git – rather part of some further UI that displays such information conveniently.
forgingahead 2y ago
Thanks for sharing the link. I'm pulling out the valuable summary at the end. I'm not sure what you're alluding to with his language, but it's a clear and articulate post that junior devs, or folks used to working solo, should see to understand the thought process behind it. === In other words, you really shouldn't rebase stuff that has been exposed anywhere outside of your own private tree. But within your own private tree, and within the commits that have never seen the light of day, rebasing is fine. (And yes, there are exceptions. If it's a clear "throw-away tree" all the rules go out the window, of course, as long as everybody involved knows it's a throw-away tree, and know that if they pull it they have to synchronise 100% with you - so within a very tight-knit case or within a very specific small detail that is actively being worked on, those rebases with cleanups make tons of sense). ===

ruraljuror 2y ago

I like your point. The exception is if the project you work on is itself downstream, in which case maintainers will rebase those “published” commits, probably employing the same technique they use to keep their local development branches up-to-date with the downstream project.

MrDarcy 2y ago

In practice it’s fine to rebase and force push to your own published branch, even when it’s an open PR. Just mark it draft or otherwise communicate when it’s no longer a moving target.

singpolyma3 2y ago
Especially when it's an open PR. That's effectively essential in order to, say, address feedback
- spankalee 2y ago
  I try not to rebase and force push for branches under active review though. It makes it much harder for the reviewer to see the changes that have happened since they last reviewed.
  - argulane 2y ago
    That's only a problem when using GitHub. GitLab and Gerrit correctly version such force push PR updates and provide a nice view of what has changed.
  - everybodyknows 2y ago
    I version-number PR branches for upstreams on GitHub. If my branch 'for-upstream-13.0' does not apply cleanly on top of upstream 'main', I sync my fork's 'main' to upstream in GitHub's Web GUI, fetch to my desktop, and build a new 'for-upstream-13.1' on top, with the help of git-cherry-pick. Might need a new PR. All history is preserved, both on GH and locally.

PaulDavisThe1st 2y ago

If you work on a branch also worked on by others, then yes, rebase is "only" possible on private commits. But if you work on a feature branch, you can publish that branch as long as everybody else understands that it is yours and nobody should push to it. Then you can safely git push --force to the feature branch so that others can (a) see what you're up to (b) test the results. When you're done, you can do a final (or only) rebase against the target branch then merge to that branch.

smcameron 2y ago
> Then you can safely git push --force What I hate about this workflow is it teaches you to git push --force. Then one day, you're in the wrong window and you accidentally git push --force on master. Much prefer a workflow where you never git push --force
- necessary 2y ago
  Git hosting platforms generally have controls that allow you to prohibit force pushes on protected branches (i.e. master)
  - The_Colonel 2y ago
    This doesn't fix the problem since you still can do a lot of damage doing that on a (perhaps wrong) feature branch.
    - SOLAR_FIELDS 2y ago
      It certainly diminishes it significantly. Very few people are usually collaborating on the same branch together that isn’t the main branch in most orgs. So the chances of you destroying yours or someone else’s work that way is pretty low. You can also branch protect any arbitrary branch, at least on GitHub, though I’ve never been in an org that protects branches other than the main one, besides an org that used release branches. I’ve also never seen someone clobber someone else’s feature branch, though it probably does happen. Much more often people are accidentally clobbering their own branches. The ability to rewrite history on feature branches is powerful in a good way and slots right into the way Git is philosophically designed. I would probably not be interested in removing that feature to prevent the rare case that someone footguns themselves or someone else

forrestthewoods 2y ago

> rebase is only possible for "private" commits. This is false. Well, it can be false. Git sucks and makes it harder then it needs to be. It’s relatively easy to have multiple people working on a feature branch that is continuously rebased. Meta’s Mercurial-like VCS system automagically stores 100% of commits in the cloud. Feature branches are anonymous rather than named. It’s all just a tree of commit hashes. Having multiple people work on one “branch” requires some basic communication as to what is considered “tip”. But since it’s all anonymous there’s no issues with different people incrementing a named branch to different commits. Honestly it’s pretty simple and easy. Git makes it harder than it actually is.

rmgk 2y ago
As far as I can tell, what is really meant by “rebase is only possible for "private" commits.” is that for public commits, rebasing would require to coordinate with everyone interested in that branch. This seems to be very similar to what you say with “requires some basic communication as to what is considered ‘tip’” Requiring coordination (or a constrained model of allowed changes) when modifying things (such as what the tip/branch points to) is a general principle unrelated to git and applies to every workflow. That said, I do understand that Meta’s centralized tool is more useful for your usecase.
- forrestthewoods 2y ago
  > I do understand that Meta’s centralized tool is more useful for your usecase. One of my chief Git complaints is that 99.9% of projects are de facto centralized on GitHub. Genuinely decentralized projects are vanishingly rare. The way Git auto-advances branch tags causes a lot of pain. Having lots of people commit to a shared feature branch that has lots of rebasing is quite easy when the “tip” is infrequently updated. Each person thinking they can declare the new tip with every commit is the source of pain.
  - rmgk 2y ago
    Again, I see where you are coming from, and I do agree that a lot of discussion about Git (and it’s workflow) is really about GitHub (and it’s workflow). But even when using GitHub as the hosting service, every time you work on a local branch (this includes main/master) you are working on something purely local that will not conflict with what anyone else is doing. It’s only by pushing/pulling that tracking branches are automatically updated, which seems to correspond to the operation that you would refer to as updating tip. As the rest of the discussion is this topic seems to indication, people do work on these “private” branches a lot, and do rebase/modify them freely to create a history as they like before publishing that history (at which point, you would require coordination with everyone who saw that to change it again). As far as I can tell, what the Meta tooling seems to offer is that you can see the “kinda private” commits of other people, if I understand correctly. That does sound indeed useful, but also out of scope for Git – rather part of some further UI that displays such information conveniently.

forgingahead 2y ago

Thanks for sharing the link. I'm pulling out the valuable summary at the end. I'm not sure what you're alluding to with his language, but it's a clear and articulate post that junior devs, or folks used to working solo, should see to understand the thought process behind it. === In other words, you really shouldn't rebase stuff that has been exposed anywhere outside of your own private tree. But within your own private tree, and within the commits that have never seen the light of day, rebasing is fine. (And yes, there are exceptions. If it's a clear "throw-away tree" all the rules go out the window, of course, as long as everybody involved knows it's a throw-away tree, and know that if they pull it they have to synchronise 100% with you - so within a very tight-knit case or within a very specific small detail that is actively being worked on, those rebases with cleanups make tons of sense). ===