I think this is a fake quote that somebody made up for an Internet comedy bit, since it seems unlikely for Hollywood actress Sydney Sweeney to have such uncharacteristically strong opinion on software version control, of all things.
Because she of all people would know that there isn’t anything wrong with using
git merge, and it ultimately comes down to personal preference to what you are used to.Fair point, Margot Robbie
That’s esteemed Academy Award nominated character actress Margot Robbie to you!
She’s modest too!
“Don’t always trust what you read on the internet.”
- Benjamin Franklin
Wait a second, there wasn’t even any social media sites back when Benjamin Franklin lived. Did he write that in his newsletter or something?
I think he was a senior contributor for the underground cracker mag 1600 back in the late 80s.
They called em zines.
Truly he was ahead of his time.
Margot Robbie, I was about to agree with you and thought that was a very reasonable take, until you tried to argue that
git mergeis better thangit rebase, then I simply had to disregard the whole thing.This is why Sydney Sweeney isn’t on Lemmy.
She probably is, just anonymous. It would be crazy to expect anyone to post on lemmy under their real name.
I think this is a fake quote that somebody made up for an Internet comedy bit
You can tell by the pixels
Why is anyone using X in 2024?
I do, I have yet to switch to Wayland
Imagine rewring history
I prefer to rebase as well. But when you’re working with a team of amateurs who don’t know how to use a VCS properly and never update their branc with the parent branch, you end up with lots of conflicts.
I find that for managing conflicts, rebase is very difficult as you have to resolve conflicts for every commit. You can either use rerere to repeat the conflict resolution automatically, or you can squash everything. But when you’re dealing with a team of Git-illiterate developers (which is VERY often the case) you can either spend the time to educate them and still risk having problems because they don’t give a shit, or you can just do a regular merge and go on with your life.
Those are my two cents, speaking from experience.
How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.
I don’t want squashed commits. It makes git tools worse (
git bisect,git cherry-pick, etc.) and I work very hard to craft a meaningful set of commits for my work and I don’t want to throw all of that away.But yeah, I don’t actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.
ITT: people who have no idea how rebasing works.
Skill issue tbh
No doubt.
git rebaseis like a very sharp knife. In the right hands, it can accomplish great things, but in the wrong hands, it can also spell disaster.As someone who HAS used it a fair amount, I generally don’t even recommend it to people unless they’re already VERY comfortable with the rest of git and ideally have some sense of how it works internally.
Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do
git rebase --interactive, since if anything goes wrong, you can easily get out withgit rebase --abort.In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.
You can get in some pretty serious messes, though. Any workflow that involves force-pushing or rebasing has the potential for data loss… Either in a literally destructive way, or in a “Seriously my keys must be somewhere but I have no idea where” kind of way.
When most people talk about rebase (for example) being reversible, what they’re usually saying is “you can always reverse the operation in the reflog.” Well yes, but the reflog is local, so if Alice messes something up with her rebase-force-push and realizes she destroyed some of Bob’s changes, Alice can’t recover Bob’s changes from her machine-- She needs to collaborate with Bob to recover them.
Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.
But it’s a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That’s not what it’s for. It’s for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.
If “we work in a way that only one person can commit to a feature”, you may be missing the point of collaborative distributed development.
I know this is a meme post, but can someone succinctly explain rebase vs merge?
I am an amateur trying to learn my tool.
Merge gives an accurate view of the history but tends to be “cluttered” with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.
Personally I prefer merge because when I’m tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it’s out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it’s included in the commits instead of existing separately outside the commits.
I honestly can’t see the point of a rebased A->B->C history because (a) it’s inaccurate and (b) it makes debugging harder. Maybe I’m missing some major benefit? I’m willing to learn.
