3 ms·

Done right and understood, it is as simple as merging, if conflicts arise no difference to conflicts via merge? But you get rid of those ugly merges back and f

Done right and understood, it is as simple as merging, if conflicts arise no difference to conflicts via merge? But you get rid of those ugly merges back and forth and unviewable histories.. Not sure why not more people care, I guess it is a little OCD I do that for my stuff.. however the 20-50+ user projects where everyone, often multiple times merges develop or even other branches in.. really unusable history right away, lets not talk about any point later. Git has derailed to a mere backup system where you can jump back, but understanding changes later becomes impossible :( What people also rarely know: A linear history is without lies, but one can sneak additional changes into a merge commit that was in neither branch quite easy - I hate that!

no_wizard 3y ago
My biggest issue with rebase from a learners perspective is that you get conflicts that simply don’t happen with merge. I’ve had experiences where I’m trying to rebase a branch and it keeps flagging my most recent changes in the rebase when the intention is that I want all previous changes applied then as a final step show me a conflict if applicable, don’t show me one when it’s not the “final” step. Admittedly maybe I’m doing it wrong. I also don’t like how rebasing “main” onto my branch actually seemingly takes my branch and rebases it onto “main”? Maybe that’s a fault in my IDE not entirely sure
- galaxyLogic 3y ago
  I think the difficulty with rebase and merge is much about semantics. When you "rebase" what does that word suggest to you? To me it sounds like "Base Again". So I'm changing the base from which I started the current branch to something else? Not quite. That would mean that my old base is REPLACED by something else, right? Instead rebase means take some other branch then put all the changes in the current branch on top of it, keeping everything in the current branch but just adding them on top of something else, right? It grokked with me when in my IDE (WebStorm) I saw the menu-option allowing me to choose another branch and perform "Check Out and Rebase on top of the current branch". So you don't just "rebase a branch", you combine two branches. And when you combine two things here the order matters, and it is easy to confuse the order. Similarly if you merge two branches, which one overrides? The left or the right operand? It is easy to get confused. Maybe I am. It is not my fault.
  - jfengel 3y ago
    It does not help that git really is checkpoints rather than deltas. The semantic difference is usually ignorable, but it can matter when you're trying to rewrite history. It's coming up with deltas on the fly, and if it gets confused it can get very very lost. Every rebase really is at least three branches: what you're merging into, where you started, and where you are now. And God help you if somebody rewrote history on any of those. The fact that all of these have terrible names makes it so much worse.
charrondev 3y ago
In my org we require all important data to be listed on a pull request, then enforce squash merge. If you have multiple distinct changes you want reflected in the history then you make multiple PRs. This makes bisecting a lot easier too.
- kazinator 3y ago
  "enforce squash merge" == "pretend Git is Visual Source Safe or CVS"
- jfengel 3y ago
  I really wish git bisect understood merges better, so that you didn't have to fake it with squash.
formerly_proven 3y ago
> Not sure why not more people care Most people don't care about most stuff, it's pretty normal. But here specifically: Most developers don't read code, nor documentation, and essentially no one reads commit messages. VCS is a WOLM - write-only linear memory - to most developers. That's probably also why most people don't care to write any kind of reasonable commit message - the software requires them to input something, so something is input - and also do not care about unreadable (and also unusable) VCS histories. They're never looking at it, it's only written. Hence it's meaningless for them if it is extremely difficult to trace changes or hard to bisect, they don't even attempt such things. There's a reason the history browsers in all the online tools and IDEs effin suck, it's because on average nobody uses history. I know, I know, this gets across very elitistically, but it's just how most people do their jobs. They get bugged to do a thing, so they sort of do the thing in order to not be bugged any more about it. I'm pretty sure that caring for these things is some kind of OCD like you say, i.e. a mental disorder.

no_wizard 3y ago

My biggest issue with rebase from a learners perspective is that you get conflicts that simply don’t happen with merge. I’ve had experiences where I’m trying to rebase a branch and it keeps flagging my most recent changes in the rebase when the intention is that I want all previous changes applied then as a final step show me a conflict if applicable, don’t show me one when it’s not the “final” step. Admittedly maybe I’m doing it wrong. I also don’t like how rebasing “main” onto my branch actually seemingly takes my branch and rebases it onto “main”? Maybe that’s a fault in my IDE not entirely sure

galaxyLogic 3y ago
I think the difficulty with rebase and merge is much about semantics. When you "rebase" what does that word suggest to you? To me it sounds like "Base Again". So I'm changing the base from which I started the current branch to something else? Not quite. That would mean that my old base is REPLACED by something else, right? Instead rebase means take some other branch then put all the changes in the current branch on top of it, keeping everything in the current branch but just adding them on top of something else, right? It grokked with me when in my IDE (WebStorm) I saw the menu-option allowing me to choose another branch and perform "Check Out and Rebase on top of the current branch". So you don't just "rebase a branch", you combine two branches. And when you combine two things here the order matters, and it is easy to confuse the order. Similarly if you merge two branches, which one overrides? The left or the right operand? It is easy to get confused. Maybe I am. It is not my fault.
- jfengel 3y ago
  It does not help that git really is checkpoints rather than deltas. The semantic difference is usually ignorable, but it can matter when you're trying to rewrite history. It's coming up with deltas on the fly, and if it gets confused it can get very very lost. Every rebase really is at least three branches: what you're merging into, where you started, and where you are now. And God help you if somebody rewrote history on any of those. The fact that all of these have terrible names makes it so much worse.

charrondev 3y ago

In my org we require all important data to be listed on a pull request, then enforce squash merge. If you have multiple distinct changes you want reflected in the history then you make multiple PRs. This makes bisecting a lot easier too.

kazinator 3y ago
"enforce squash merge" == "pretend Git is Visual Source Safe or CVS"
jfengel 3y ago
I really wish git bisect understood merges better, so that you didn't have to fake it with squash.

formerly_proven 3y ago

> Not sure why not more people care Most people don't care about most stuff, it's pretty normal. But here specifically: Most developers don't read code, nor documentation, and essentially no one reads commit messages. VCS is a WOLM - write-only linear memory - to most developers. That's probably also why most people don't care to write any kind of reasonable commit message - the software requires them to input something, so something is input - and also do not care about unreadable (and also unusable) VCS histories. They're never looking at it, it's only written. Hence it's meaningless for them if it is extremely difficult to trace changes or hard to bisect, they don't even attempt such things. There's a reason the history browsers in all the online tools and IDEs effin suck, it's because on average nobody uses history. I know, I know, this gets across very elitistically, but it's just how most people do their jobs. They get bugged to do a thing, so they sort of do the thing in order to not be bugged any more about it. I'm pretty sure that caring for these things is some kind of OCD like you say, i.e. a mental disorder.