4 ms·

The fact that rebase would ever be preferred over merge just shows how bad Git really is under the covers. It's insane that everyone is re-writing their develop

by feoren 3y ago

The fact that rebase would ever be preferred over merge just shows how bad Git really is under the covers. It's insane that everyone is re-writing their development history to avoid issues with their source control system. There's no reason that should be necessary at all. Manually intervening and re-writing history should be completely antithetical to a good source control system. And squashing should never be preferred by anyone if the tooling was actually any good. For PRs? You should be able to define a group of commits and look at it as a whole, not just operate on a single commit. For clutter? You should be able to "zoom" in and out, or collapse/expand branches in your UI. For disk space? If the size of each commit was O(size of change + small constant), then squishing wouldn't help, because you'd just be cutting out a few bytes per commit -- assuming you're not thrashing back and forth with your changes. The fact that squashing saves so much space just shows how inefficiently Git is storing things. We're all suffering that Mercurial lost the war. Of course, even Mercurial isn't perfect. Why did we stop innovating on source control systems a decade ago?

brianzelip 3y ago
I dunno…leveraging retrospect is often useful.
- deleted 3y ago
  [deleted]
- MrDarcy 3y ago
  Extremely useful almost every time. Why wouldn’t we re-write our personal history just before merging into the main permanent history?
  - interroboink 3y ago
    I'm not a proponent of it, but some people would say: including all the messy history is a more honest representation of what actually happened. By that school of thought, a repo should be recording what happened, not what you want to look like happened. I haven't found it to be terribly useful though. IME, it adds noise for future code archeologists. In very rare cases, having the messy long history can be slightly more useful for bisecting to find precisely where bugs were introduced, simply because it's more fine-grained.
    - ninkendo 3y ago
      > including all the messy history is a more honest representation of what actually happened I don’t think anyone needs to see the hundred incantations of `git commit -a -m fuckfuckfuck` I do before I make a PR. To those who say “you should make meaningful commit messages” I say “yeah that’s what you see in the single commit when I make the PR”. If you say “you should just not commit until your local work is PR worthy”, I would say you’re not using git effectively.
    - cryptonector 3y ago
      > I'm not a proponent of it, but some people would say: including all the messy history is a more honest representation of what actually happened. By that logic you should leave typos in, because, you know, it's "more honest". Or you should not edit yourself in any way, because it's "more honest". The reality is that not editing our communications, or our commit history, is a lack of respect to others, especially when that lack of editing imposes a higher cognitive burden on others (e.g., having to sift through more hay to find needles).
      - interroboink 3y ago
        I think those proponents would indeed say to include the typos. And then also include the change where you fixed the typos, and so on. I didn't mean to imply any moral or dogmatic concept of "honesty" here. It only means there is less guessing about what events actually transpired. But as you say, I agree it most often just adds noise, in my experiences.
        cryptonector 3y ago
        > But as you say, I agree it most often just adds noise, in my experiences. But critically, that noise is a lack of respect towards others.
        interroboink 3y ago
        As with all things, context matters. It would depend on what those others want, what the team culture is, etc. I could imagine a group of these hypothetical "maximum honesty" people working together happily, and respectfully, in their way.
  - cryptonector 3y ago
    > Why wouldn’t we re-write our personal history just before merging into the main permanent history? Mainly because it's more work. But it's work worth doing. It's also enjoyable.
lifeisstillgood 3y ago
I cannot grasp that at all. To rebase I take your patches, apply them, then I apply my patches, fixing any trip ups. You "got in" first, so I get to do the work. It seems simple to me - far more than hoping merges do what we both meant. Conceptually, it's patches all the way down - anything else is to me suspect ... might be me not being big brained enough :-)
- feoren 3y ago
  In both cases we're just "hoping" that the result is what we want. Merging is acknowledging the parallel development and explicitly dealing with it; rebasing is pretending it never happened and applying my patches on top of a codebase that I have never seen before. In my experience, rebasing is much more likely to fail in weird and dangerous ways. But I'll admit Git's merging leaves a lot to be desired too -- that's part of what I'm complaining about, and what attracts people to rebase.
  - lifeisstillgood 3y ago
    Then I think that the complexity is kind of inherent. Firstly it's only a codebase I have never seen before because I am not keeping up with the changes. Ideally i will pause during rebase carefully read the commits which will include long thoughtful messages laying out important implications, and my tooling will make clear where the conflicts lie, and how test coverage is affected. We won't ever just grep for <<<<<< and try and remember which HEAD means - is that mine or yours? I am making changes against an evolving codebase. Either I am talking with people editing that codebase and we are in sympathy or we are hoping a VCS will solve our political and organisational problems. I honestly think having time to argue about the best way to solve a problem amoung a team is the best solution - let the team talk argue and decide and they will barely need a VCS. If you cannot "spare the time we must deliver" you got other problems Edit: Look honestly it's all patches. That's the atomic level. And to my mind, having you gather the freshest version of the codebase then apply your chnage son top is the sanest cleanest approach. The same merge conflict resolution applies - I agree. (basically line conflicts). But what's the option? Anything else gets weirder faster (seen some trying to understand conflicts in functions, etc)
cryptonector 3y ago
> The fact that rebase would ever be preferred over merge just shows how bad Git really is under the covers. It's insane that everyone is re-writing their development history to avoid issues with their source control system. It's local history that one rewrites, so there's nothing "insane" about it. What your comment does is expose your lack of understanding of this matter. > We're all suffering that Mercurial lost the war. Of course, even Mercurial isn't perfect. Why did we stop innovating on source control systems a decade ago? Mercurial supports rebasing and history rewriting just fine.
- feoren 3y ago
  > It's local history that one rewrites I don't understand this. You do not back up your code to any shared repository while still working on a feature? What if it takes 2+ weeks? You have 2 weeks of code replicated only locally on your laptop? Or what do you mean by local?
  - interroboink 3y ago
    I'm not the person you asked, but I think they meant: changes that are not shared with others. You can back up your own stuff as you please, but once you share it with someone else, it's best to treat that bit of repo history as immutable from that point onward (because they may have made their own copies, shared it with other people, etc). So I think what people are saying (and I largely agree with them) is that it's fine to rewrite history as long as you never share the ugly mess that existed before the rewrite with others. A typical example of this is having un-shared ("local" - but could be backed up) streams of "tweak a comment, fix a semicolon, xxx" changesets that aren't really going to be useful to other people. Before you share with others, you squash them down to a single (or few) "implement feature X" kind of changes, often with linear history. Having that less-branchy and less-noisy linear history available is useful in the future when you want to examine the history of the repo. Future people don't need to know that you fixed a comment, added a semicolon, etc. They want to know the big coherent logical changes that were applied to the repo. Squasing/rebasing/fixing history before you share it allows you to have your cake and eat it too, more or less. ---- EDIT: Here's a decent email from Torvalds on the subject (not that I agree w/him about everything, but in this case): https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net...
asylteltine 3y ago
I agree. Mercurial at Meta was THE BEST version control experience I ever had. In 2023, git is worse than mercurial. Stack sets are superior.
- 1letterunixname 3y ago
  Yes. The absence of staging area and the single path of development controlled by diff approvals and landing were major improvements. But Meta's "hg" wasn't really FOSS hg for a long time and looks nothing like it today. It started as hg but was hacked to become what is now sort of Sapling (+ Mononoke + Eden + Buck + Phabricator + Sandcastle + Landcastle) integrated together. The lore was that the git people didn't want to help improve monorepo performance, but the hg people were somewhat more interested so that was the reason behind hg. Then later, Microsoft got git people to upstream changes to accomplish similar performance improvements. IMO, efficient monorepo dev cannot happen without an SCM-integrated synthetic FS. Also, efficient dev cannot happen without dependencies-aware testing and build caching. It further helps if dev tools are tightly integrated together and documented. Meta didn't do documentation well and didn't name things all that well either. Most internal tools also lacked man pages and generally depend on in-group knowledge hoarding rather than self-discovery and principle of least surprise. Every now and then, some critical tool (to your workflow) group would come along, break their tools, and leave them broken for weeks with a flimsy excuse like "Oh yeah, our news people are rewriting it in Rust" rather than reverting to a working build.
hasty_pudding 3y ago
> It's insane that everyone is re-writing their development history to avoid issues with their source control system people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing. I would have the same problem on any VCS > And squashing should never be preferred by anyone if the tooling was actually any good. For PRs? You should be able to define a group of commits and look at it as a whole, not just operate on a single commit. For clutter? once again responsible commits are supposed to be small, isolated, single change commits. so in a large feature a good developer would have tons of commits this makes the PR easier to understand and review... and when the features finally merged, you don't necessarily need those commits you just need the feature. I think your issue might just be with understanding how version control is supposed to work.
- feoren 3y ago
  > I think your issue might just be with understanding how version control is supposed to work. This has nothing to do with how it's "supposed to" work, and all to do with the standards and constraints we're putting on ourselves here. No god has made any commandments about how thou shalt organize your commits. > I would have the same problem on any VCS ... commits are supposed to be small, isolated, single change commits It sounds to me like you've got some self-imposed issues. Nobody told you every commit has to be a "single change", unless you're very loose with what you mean by that. Sure, a commit should be a group of related functionality, such that you either want all of it or none of it. But it's perfectly fine for one commit to involve 20+ files. In fact one of the (many) things people hated about CVS was that you couldn't bundle changes like this! And if you're that concerned about commits being single changes, then you should never squash! It's hypocritical to say every commit should be tiny, but then squash them! > this makes the PR easier to understand and review I already addressed this. The problem is the 1:1 mapping between commits and PRs. There's no reason for that.
- nonethewiser 3y ago
  > people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing. Its a good ideal but not realistic.
lolinder 3y ago
> Manually intervening and re-writing history should be completely antithetical to a good source control system. The way I use git, it's not "history" until it's in main. Up until that point, branches are mutable sequences of patches that may or may not ever get merged in. These patches bear little resemblance to the actual sequence in which I developed the code: as often as not, I'll amend a commit rather than creating a new one, because the point of the version control system for me isn't to faithfully log what I did, it's to represent my change as a discrete sequence of steps to get from main to main+feature. Viewed that way, rebase is obviously the preferred way to integrate main->feature branch. Main has changed under me in some way that causes a conflict, so I need to reevaluate my sequence of patches in light of the new information. When it comes to integrating feature->main, I don't have a strong opinion, except that squash is terrible because I specifically designed the commits to make sense as distinct steps.
seeknotfind 3y ago
Doing the extra work to rebase makes git bisect a lot more tenable, and it simplifies the view of history. You don't have to make this tradeoff, but some might want to.
deleted 3y ago
[deleted]

by feoren 3y ago

brianzelip 3y ago

I dunno…leveraging retrospect is often useful.

deleted 3y ago
[deleted]
MrDarcy 3y ago
Extremely useful almost every time. Why wouldn’t we re-write our personal history just before merging into the main permanent history?
- interroboink 3y ago
  I'm not a proponent of it, but some people would say: including all the messy history is a more honest representation of what actually happened. By that school of thought, a repo should be recording what happened, not what you want to look like happened. I haven't found it to be terribly useful though. IME, it adds noise for future code archeologists. In very rare cases, having the messy long history can be slightly more useful for bisecting to find precisely where bugs were introduced, simply because it's more fine-grained.
  - ninkendo 3y ago
    > including all the messy history is a more honest representation of what actually happened I don’t think anyone needs to see the hundred incantations of `git commit -a -m fuckfuckfuck` I do before I make a PR. To those who say “you should make meaningful commit messages” I say “yeah that’s what you see in the single commit when I make the PR”. If you say “you should just not commit until your local work is PR worthy”, I would say you’re not using git effectively.
  - cryptonector 3y ago
    > I'm not a proponent of it, but some people would say: including all the messy history is a more honest representation of what actually happened. By that logic you should leave typos in, because, you know, it's "more honest". Or you should not edit yourself in any way, because it's "more honest". The reality is that not editing our communications, or our commit history, is a lack of respect to others, especially when that lack of editing imposes a higher cognitive burden on others (e.g., having to sift through more hay to find needles).
    - interroboink 3y ago
      I think those proponents would indeed say to include the typos. And then also include the change where you fixed the typos, and so on. I didn't mean to imply any moral or dogmatic concept of "honesty" here. It only means there is less guessing about what events actually transpired. But as you say, I agree it most often just adds noise, in my experiences.
      - cryptonector 3y ago
        > But as you say, I agree it most often just adds noise, in my experiences. But critically, that noise is a lack of respect towards others.
        interroboink 3y ago
        As with all things, context matters. It would depend on what those others want, what the team culture is, etc. I could imagine a group of these hypothetical "maximum honesty" people working together happily, and respectfully, in their way.
- cryptonector 3y ago
  > Why wouldn’t we re-write our personal history just before merging into the main permanent history? Mainly because it's more work. But it's work worth doing. It's also enjoyable.

lifeisstillgood 3y ago

I cannot grasp that at all. To rebase I take your patches, apply them, then I apply my patches, fixing any trip ups. You "got in" first, so I get to do the work. It seems simple to me - far more than hoping merges do what we both meant. Conceptually, it's patches all the way down - anything else is to me suspect ... might be me not being big brained enough :-)

feoren 3y ago
In both cases we're just "hoping" that the result is what we want. Merging is acknowledging the parallel development and explicitly dealing with it; rebasing is pretending it never happened and applying my patches on top of a codebase that I have never seen before. In my experience, rebasing is much more likely to fail in weird and dangerous ways. But I'll admit Git's merging leaves a lot to be desired too -- that's part of what I'm complaining about, and what attracts people to rebase.
- lifeisstillgood 3y ago
  Then I think that the complexity is kind of inherent. Firstly it's only a codebase I have never seen before because I am not keeping up with the changes. Ideally i will pause during rebase carefully read the commits which will include long thoughtful messages laying out important implications, and my tooling will make clear where the conflicts lie, and how test coverage is affected. We won't ever just grep for <<<<<< and try and remember which HEAD means - is that mine or yours? I am making changes against an evolving codebase. Either I am talking with people editing that codebase and we are in sympathy or we are hoping a VCS will solve our political and organisational problems. I honestly think having time to argue about the best way to solve a problem amoung a team is the best solution - let the team talk argue and decide and they will barely need a VCS. If you cannot "spare the time we must deliver" you got other problems Edit: Look honestly it's all patches. That's the atomic level. And to my mind, having you gather the freshest version of the codebase then apply your chnage son top is the sanest cleanest approach. The same merge conflict resolution applies - I agree. (basically line conflicts). But what's the option? Anything else gets weirder faster (seen some trying to understand conflicts in functions, etc)

cryptonector 3y ago

> The fact that rebase would ever be preferred over merge just shows how bad Git really is under the covers. It's insane that everyone is re-writing their development history to avoid issues with their source control system. It's local history that one rewrites, so there's nothing "insane" about it. What your comment does is expose your lack of understanding of this matter. > We're all suffering that Mercurial lost the war. Of course, even Mercurial isn't perfect. Why did we stop innovating on source control systems a decade ago? Mercurial supports rebasing and history rewriting just fine.

feoren 3y ago
> It's local history that one rewrites I don't understand this. You do not back up your code to any shared repository while still working on a feature? What if it takes 2+ weeks? You have 2 weeks of code replicated only locally on your laptop? Or what do you mean by local?
- interroboink 3y ago
  I'm not the person you asked, but I think they meant: changes that are not shared with others. You can back up your own stuff as you please, but once you share it with someone else, it's best to treat that bit of repo history as immutable from that point onward (because they may have made their own copies, shared it with other people, etc). So I think what people are saying (and I largely agree with them) is that it's fine to rewrite history as long as you never share the ugly mess that existed before the rewrite with others. A typical example of this is having un-shared ("local" - but could be backed up) streams of "tweak a comment, fix a semicolon, xxx" changesets that aren't really going to be useful to other people. Before you share with others, you squash them down to a single (or few) "implement feature X" kind of changes, often with linear history. Having that less-branchy and less-noisy linear history available is useful in the future when you want to examine the history of the repo. Future people don't need to know that you fixed a comment, added a semicolon, etc. They want to know the big coherent logical changes that were applied to the repo. Squasing/rebasing/fixing history before you share it allows you to have your cake and eat it too, more or less. ---- EDIT: Here's a decent email from Torvalds on the subject (not that I agree w/him about everything, but in this case): https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net...

asylteltine 3y ago

I agree. Mercurial at Meta was THE BEST version control experience I ever had. In 2023, git is worse than mercurial. Stack sets are superior.

1letterunixname 3y ago
Yes. The absence of staging area and the single path of development controlled by diff approvals and landing were major improvements. But Meta's "hg" wasn't really FOSS hg for a long time and looks nothing like it today. It started as hg but was hacked to become what is now sort of Sapling (+ Mononoke + Eden + Buck + Phabricator + Sandcastle + Landcastle) integrated together. The lore was that the git people didn't want to help improve monorepo performance, but the hg people were somewhat more interested so that was the reason behind hg. Then later, Microsoft got git people to upstream changes to accomplish similar performance improvements. IMO, efficient monorepo dev cannot happen without an SCM-integrated synthetic FS. Also, efficient dev cannot happen without dependencies-aware testing and build caching. It further helps if dev tools are tightly integrated together and documented. Meta didn't do documentation well and didn't name things all that well either. Most internal tools also lacked man pages and generally depend on in-group knowledge hoarding rather than self-discovery and principle of least surprise. Every now and then, some critical tool (to your workflow) group would come along, break their tools, and leave them broken for weeks with a flimsy excuse like "Oh yeah, our news people are rewriting it in Rust" rather than reverting to a working build.

hasty_pudding 3y ago

> It's insane that everyone is re-writing their development history to avoid issues with their source control system people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing. I would have the same problem on any VCS > And squashing should never be preferred by anyone if the tooling was actually any good. For PRs? You should be able to define a group of commits and look at it as a whole, not just operate on a single commit. For clutter? once again responsible commits are supposed to be small, isolated, single change commits. so in a large feature a good developer would have tons of commits this makes the PR easier to understand and review... and when the features finally merged, you don't necessarily need those commits you just need the feature. I think your issue might just be with understanding how version control is supposed to work.

feoren 3y ago
> I think your issue might just be with understanding how version control is supposed to work. This has nothing to do with how it's "supposed to" work, and all to do with the standards and constraints we're putting on ourselves here. No god has made any commandments about how thou shalt organize your commits. > I would have the same problem on any VCS ... commits are supposed to be small, isolated, single change commits It sounds to me like you've got some self-imposed issues. Nobody told you every commit has to be a "single change", unless you're very loose with what you mean by that. Sure, a commit should be a group of related functionality, such that you either want all of it or none of it. But it's perfectly fine for one commit to involve 20+ files. In fact one of the (many) things people hated about CVS was that you couldn't bundle changes like this! And if you're that concerned about commits being single changes, then you should never squash! It's hypocritical to say every commit should be tiny, but then squash them! > this makes the PR easier to understand and review I already addressed this. The problem is the 1:1 mapping between commits and PRs. There's no reason for that.
nonethewiser 3y ago
> people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing. Its a good ideal but not realistic.

lolinder 3y ago

> Manually intervening and re-writing history should be completely antithetical to a good source control system. The way I use git, it's not "history" until it's in main. Up until that point, branches are mutable sequences of patches that may or may not ever get merged in. These patches bear little resemblance to the actual sequence in which I developed the code: as often as not, I'll amend a commit rather than creating a new one, because the point of the version control system for me isn't to faithfully log what I did, it's to represent my change as a discrete sequence of steps to get from main to main+feature. Viewed that way, rebase is obviously the preferred way to integrate main->feature branch. Main has changed under me in some way that causes a conflict, so I need to reevaluate my sequence of patches in light of the new information. When it comes to integrating feature->main, I don't have a strong opinion, except that squash is terrible because I specifically designed the commits to make sense as distinct steps.

seeknotfind 3y ago

Doing the extra work to rebase makes git bisect a lot more tenable, and it simplifies the view of history. You don't have to make this tradeoff, but some might want to.

deleted 3y ago

[deleted]