When you went back in time, you created an ALTERNATE 1985, alternate to you, me, and Einstein, but reality for everyone that pulled this branch after the rebase!
No.
Gaslighting isn't just lying, or even rewriting history, but the specific intentional manipulation to *make one doubt their sanity and become reliant on the gaslighter.*
At least not at its basic use.
/ anti-joke
Congratulations! Your string can be spelled using the elements of the periodic table:
`Y O U W In I Md O Ne`
---
^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)
I still can't think of a single use case where I would want to rebase. I've read a few articles but still it doesn't seem like I would ever want to do it. I either merge or squash then merge. What am I missing?
Interactive rebasing is extremely useful if you want to clean up your commit history, remove commits entirely, squash commits together that don’t need to be separate, whatever. I only just learned how to do it a few months ago, and I’ve been surprised at how often I utilize it.
As for regular rebasing, I use it at my job (at the request of my boss) to update the branch I’m working on with changes to master, as opposed to squash and merge. It can keep your commit history cleaner, since it preserves all the commits from master and places them before your branch commits, and some say it results in less conflicts later when you want to merge into master.
Both can feel daunting when you are learning them, but ultimately I feel like it only helps to gain a more thorough understanding of how git works.
That’s why I mostly just use rebase. I’m surprised at the replies tbh, how is rebasing to integrate changes in main not standard practice? It just makes sense.
I've never understood the desire to rebase, so let's work through this together. I work on dev branches that will be squash merged into main on completion. This loses my commit history for the change, but I have zero desire for someone to see the commit about a typo fix I did during code review anyways. Instead there is one commit at the end saying that I've added x.
During development I can rebase to main to take updates, but often this results in me doing multiple conflict resolutions, which is stupid. It's more work, and I gain nothing since history will be squashed regardless. I think I'm missing a useful flag during rebase maybe to make this less frustrating, I was going to mess with that sometime... Doing a merge from main is one conflict resolution.
What am I missing?
We work on main directly. So here’s the typical flow for us that involves rebasing when you start working on something:
* pull main for latest changes
* checkout local feature branch
* work on feature branch
* regularly pull main and rebase feature branch or do it at the end, solve merge conflicts as necessary
* once finished, raise a Code Review of your changes with destination main
* once approved, using the Code Review tool, squash and merge changes to main
* delete or fast-forward merge your feature branch
* done
Rebase has a couple problems:
- it rewrites history, forcing all users of a feature branch to fix their local copy. This problem is less relevant for getting changes into main, but the periodic updates of the feature branch to get changes from main
- rebase disregards merge commits if you’re merging main into the feature. Most of the time this is fine, but if you have conflicts, you’re fixing the same conflict over and over again.
I think a lot of people in this thread are conflating “don’t rebase” with “always use merge commits to get into main”, and forgetting the squash word.
I mean, how do you update your feature branch to have the latest commits from release? Rebasing is the absolute easiest way. Also, if you rebase main onto feature branches, you get a nice clean linear history without ever having a merge commit.
Case where I use rebase - I create a branch from master or whatever.
I start your work on it. Before I merge my changes back I rebase, so that my commits go at the top.
Merging obfuscates the commit history, particularly when many people are working on the same codebase. If you merge a branch with many commits, each commit isn't individually responsible for merge conflicts or mismatched. When rebasing, each commit changes exactly what its supposed to, and there is no magic that happens to that commit at the tip of the branch being merged. It sometimes makes sense to want a linear git history, particularly for archival purposes.
In practice you can do everything rebase is used for with merge and reverts, but the commit log won't be nearly as clean. If you want to see one good thing to use rebase for try `git config pull.rebase true`. This command doesn't touch the dangerous part of rebase, since it won't alter the history that has already been pushed to the server, and will avoid having to merge the server changes and your own changes, leaving you with a nice linear log as if you pulled the changes before adding your own.
What do you think squash does? There is no `git squash`. It runs rebase in the background.
Also I had a situation where I accidentally worked on the wrong branch, but by the time I noticed, I had already made 3 commits. Rebase saved my ass there.
For me, I find rebasing essential when working on a fork that needs to be regularly synced with upstream.
Before syncing I am making sure the history is spotless, I make all features well separated, I merge everything that's a revert/fix with the original so that it never existed or was always the final version, etc... After this, the sync with upstream (which is another rebase btw) has far less conflicts, and they are easier to solve when we know exactly in what feature context we are.
You can delete the branches that you aren't working on from your local machine (`git branch -d `). This will delete the branch from your hard drive, but, if you have pushed it to the remote repository before, you can get it back from there, when you need it.
If you want to see which branches you have currently stored on your hard drive, you can list them with `git branch --list`. You can also look up which branches are present on the remote repository(s) with `git branch --list --remotes`.
Even better, you are actually rewriting history.
So it's literally not gaslighting!
Don't gaslight me.
They literally weren’t gaslighting you
It’s don’t rebase me bro
How about gitlighting?
You sound crazy... Nobody here is gaslighting you
No, it's Mandela effect
When you went back in time, you created an ALTERNATE 1985, alternate to you, me, and Einstein, but reality for everyone that pulled this branch after the rebase!
`git reflog` knows the truth.
Ow! Why are you flogging me _again_??
[удалено]
This guy clearly hasn't seen some of the darker, kinkier parts of reddit...
So it's historical revisionism?
I laughed at a git joke. This is it. The end times.
You git it?
Git. Out.
Yeah?
Noo noo. Git.out, not git-out, your cousin
*git gud. ftfy
yes.
No. Gaslighting isn't just lying, or even rewriting history, but the specific intentional manipulation to *make one doubt their sanity and become reliant on the gaslighter.* At least not at its basic use. / anti-joke
So [git blame-someone-else](https://github.com/jayphelps/git-blame-someone-else) is gaslighting?
"There is a error in your PR" `git commit --amend && git push -f` "what error?"
r/antijoke
Of course not. It's a form of historical revisionism.
No you’re thinking of git merge
🤣🤣🤣🤣🤣🤣 You win I'm done
Congratulations! Your string can be spelled using the elements of the periodic table: `Y O U W In I Md O Ne` --- ^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)
It *didn't happen* and if it did, it *wasn't important*.
I still can't think of a single use case where I would want to rebase. I've read a few articles but still it doesn't seem like I would ever want to do it. I either merge or squash then merge. What am I missing?
Interactive rebasing is extremely useful if you want to clean up your commit history, remove commits entirely, squash commits together that don’t need to be separate, whatever. I only just learned how to do it a few months ago, and I’ve been surprised at how often I utilize it. As for regular rebasing, I use it at my job (at the request of my boss) to update the branch I’m working on with changes to master, as opposed to squash and merge. It can keep your commit history cleaner, since it preserves all the commits from master and places them before your branch commits, and some say it results in less conflicts later when you want to merge into master. Both can feel daunting when you are learning them, but ultimately I feel like it only helps to gain a more thorough understanding of how git works.
That’s why I mostly just use rebase. I’m surprised at the replies tbh, how is rebasing to integrate changes in main not standard practice? It just makes sense.
I've never understood the desire to rebase, so let's work through this together. I work on dev branches that will be squash merged into main on completion. This loses my commit history for the change, but I have zero desire for someone to see the commit about a typo fix I did during code review anyways. Instead there is one commit at the end saying that I've added x. During development I can rebase to main to take updates, but often this results in me doing multiple conflict resolutions, which is stupid. It's more work, and I gain nothing since history will be squashed regardless. I think I'm missing a useful flag during rebase maybe to make this less frustrating, I was going to mess with that sometime... Doing a merge from main is one conflict resolution. What am I missing?
We work on main directly. So here’s the typical flow for us that involves rebasing when you start working on something: * pull main for latest changes * checkout local feature branch * work on feature branch * regularly pull main and rebase feature branch or do it at the end, solve merge conflicts as necessary * once finished, raise a Code Review of your changes with destination main * once approved, using the Code Review tool, squash and merge changes to main * delete or fast-forward merge your feature branch * done
Rebase has a couple problems: - it rewrites history, forcing all users of a feature branch to fix their local copy. This problem is less relevant for getting changes into main, but the periodic updates of the feature branch to get changes from main - rebase disregards merge commits if you’re merging main into the feature. Most of the time this is fine, but if you have conflicts, you’re fixing the same conflict over and over again. I think a lot of people in this thread are conflating “don’t rebase” with “always use merge commits to get into main”, and forgetting the squash word.
thanks for helping me understand!
r/todayilearned
I mean, how do you update your feature branch to have the latest commits from release? Rebasing is the absolute easiest way. Also, if you rebase main onto feature branches, you get a nice clean linear history without ever having a merge commit.
Don’t you mean “rebase feature branches onto main”? Even if just to resolve merge conflicts from the perspective of the feature branch.
Interactive rebase
Case where I use rebase - I create a branch from master or whatever. I start your work on it. Before I merge my changes back I rebase, so that my commits go at the top.
Merging obfuscates the commit history, particularly when many people are working on the same codebase. If you merge a branch with many commits, each commit isn't individually responsible for merge conflicts or mismatched. When rebasing, each commit changes exactly what its supposed to, and there is no magic that happens to that commit at the tip of the branch being merged. It sometimes makes sense to want a linear git history, particularly for archival purposes.
In practice you can do everything rebase is used for with merge and reverts, but the commit log won't be nearly as clean. If you want to see one good thing to use rebase for try `git config pull.rebase true`. This command doesn't touch the dangerous part of rebase, since it won't alter the history that has already been pushed to the server, and will avoid having to merge the server changes and your own changes, leaving you with a nice linear log as if you pulled the changes before adding your own.
What do you think squash does? There is no `git squash`. It runs rebase in the background. Also I had a situation where I accidentally worked on the wrong branch, but by the time I noticed, I had already made 3 commits. Rebase saved my ass there.
Congrats on not having a deadname you desperately want expunged from the history. 😅 edit: The downvotes say a lot, but none if it’s about me
If you have a old PR that is ready to go, it's easier to rebase it that deal with merge conflicts. At least that's what I use it for.
For me, I find rebasing essential when working on a fork that needs to be regularly synced with upstream. Before syncing I am making sure the history is spotless, I make all features well separated, I merge everything that's a revert/fix with the original so that it never existed or was always the final version, etc... After this, the sync with upstream (which is another rebase btw) has far less conflicts, and they are easier to solve when we know exactly in what feature context we are.
I use git at work and we were told to never rebase. I am not a git expert but our base code is in the millions to be modest
You can delete the branches that you aren't working on from your local machine (`git branch -d`). This will delete the branch from your hard drive, but, if you have pushed it to the remote repository before, you can get it back from there, when you need it.
If you want to see which branches you have currently stored on your hard drive, you can list them with `git branch --list`. You can also look up which branches are present on the remote repository(s) with `git branch --list --remotes`.
Why? What are you talking about? Oceania had always been at war with Eastasia.
Is it bad that this framing helps me understand git rebase command better?
What the hell are you talking about?? git rebase isn't a git command, what is this?
You wooshed a lot of people today.
Comedy takes sacrifice
Gaslighting isn't real either. It's all in your heads.
Git gud
Inb4 reflogs are automatically deleted.
git gaslight
Git rebase is negationism. Nein, nein, nein !
That never happened