> No one cares if under the hood a rebase is technically a merge that forgets where it came from. I mean, isn't that the whole point of a rebase?
Hurting people is the point of a gun, that doesn't mean guns are suddenly excused from doing so.
> The whole point of a rebase is to move your local branch onto the tip of another branch while preserving the local history.
But you aren't; history is as much about where you came from as where you are now.
> The goal is to simplify the repository history by eliminating irrelevant noise.
Because merges aren't noise, they are fallible events just like manual changes. They also help to group changes together and provide helpful context.
> That's not a problem, it's a solution. How can they possibly miss the extra forks and joins in their commit graph? Do they not see that? Do they spend any time looking at commit graphs?
If you don't want to see the merges, hide them. `git log --first-parent` shows you the commit history as if all merges were squashes instead.
Meanwhile, the rest of us can suddenly appreciate having the extra context available when it's actually needed.
> It's ok if Fossil's devs want to force their opinionated take on VCS onto Fossil's users, but this does not mean they are right or have a point.
Deleting data is opinionated, preserving it leaves it up to the reader to judge.
But my point isn't that you should use Fossil, but that Git is a far better VCS if you use it as if it was Fossil.
> If there is criticism to throw at Git, rebases clearly ain't it.
In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing.
> In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing.
That means that both you and those people do not fully grasp the concept. The problem I have is that those misunderstandings are spread such that I have to deal with it. Especially those that do not understand Git at all keep merging balls of merges of merges. Then they lose track, and decide to just merge main again because something broke and they hope that Git will solve it with just one more merge.
I have no problem with incompetence, I myself am incompetent in a lot of areas, and I know that. When I have to work with people, I have a problem with those that are not able or willing to acknowledge they lack some overview.
> That means that both you and those people do not fully grasp the concept. The problem I have is that those misunderstandings are spread such that I have to deal with it. Especially those that do not understand Git at all keep merging balls of merges of merges. Then they lose track, and decide to just merge main again because something broke and they hope that Git will solve it with just one more merge.
I would take a step further and say the root cause is not users who do not fully grasp a concept of Git, but who fail to grasp one of the most fundamental aspects of version control systems: branching and merging.
Git just happens to take a bad rap because it's ubiquitous and for some it's the only VCS they ever used.
Of course a bad workman blames his tools. If the tool they are using is Git then of course that's the one being thrown under the bus.
What is perplexing is how this problem is then approached by people who are expected to know better by framing it as something only a bad tool would do, and thus they roll out yet another tool that does the same thing and poses the same problems.
In the case of jj, they even claim to fix git by running git as the backend. Think about that for a second.
That mismerge would have been just as bad if they had rebased instead, except you wouldn't have had the context to go back and fix it. How would that be better?
If your merge goes wrong, you should rip it out of your feature branch. You use git rebase -i for that, or git reset even.
But you shouldn't merge into your feature branch at all. We are interested in how your commits change what becomes before it in mainline. We are not interested in how main differed from your feature branch at various points in time.
Git rebase is wonderful for people that create mess when working. Your feature branch can contain lots of WIPs for all the times you hit five 'o clock. With interactive rebase you can clean up your mess: squash, split, delete and reorder commits. You can do this all graphically even, like drag-drop reordering of commits. Also read up about git fixup and friends for quick fixes. There is also git rebase abort if you think you are doing something wrong.
> But you aren't; history is as much about where you came from as where you are now.
No. That's clearly something you are failing to understand. Commit history is not chronological. Commit history is ordinal. I make my commits, and I say where they should go and in which order they should go. Try to understand that.
> Because merges aren't noise, they are fallible events just like manual changes.
You're not even paying attention to what you are saying. If you interpret merges are "fallible events" then what's the point of pushing a "fallible event" to a shared repository when they are irrelevant to describe your changeset? The only purpose they have is to make sure your feature branch can be merged back to mainline with the latest changes in mainline. Why introduce a "fallible event" for that?
Isn't it far simpler if you just reapply your commits on top of the branch, and leave those "fallible events" out of the commit history?
Moreover, look at the silliness of it all. What prevents anyone from manually replaying a commit history on top of another branch? Should that be prevented too? Should support for squashed merges be removed too because they lose a reference to the origin commit?
What's exactly the point you're trying to argue?
> Deleting data is opinionated, preserving it leaves it up to the reader to judge.
Try to understand this: you read what I write. No more, no less.
> In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing.
So what? Are you also going to argue to ban furniture because unsupervised toddlers can bang their heads on it?
Do you know who doesn't waste time posting remarks on rebase? People who use it all the time and don't have a problem with it.
Hurting people is the point of a gun, that doesn't mean guns are suddenly excused from doing so.
> The whole point of a rebase is to move your local branch onto the tip of another branch while preserving the local history.
But you aren't; history is as much about where you came from as where you are now.
> The goal is to simplify the repository history by eliminating irrelevant noise.
Because merges aren't noise, they are fallible events just like manual changes. They also help to group changes together and provide helpful context.
> That's not a problem, it's a solution. How can they possibly miss the extra forks and joins in their commit graph? Do they not see that? Do they spend any time looking at commit graphs?
If you don't want to see the merges, hide them. `git log --first-parent` shows you the commit history as if all merges were squashes instead.
Meanwhile, the rest of us can suddenly appreciate having the extra context available when it's actually needed.
> It's ok if Fossil's devs want to force their opinionated take on VCS onto Fossil's users, but this does not mean they are right or have a point.
Deleting data is opinionated, preserving it leaves it up to the reader to judge.
But my point isn't that you should use Fossil, but that Git is a far better VCS if you use it as if it was Fossil.
> If there is criticism to throw at Git, rebases clearly ain't it.
In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing.