Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
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!
And successful Hollywood film producer -- props on getting into the stakeholder end of the business so early in your career!
Margot Robbie, I was about to agree with you and thought that was a very reasonable take, until you tried to argue that git merge is better than git 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.
But they were arguing that it's personal preference not that one is better than the other
"Don't always trust what you read on the internet."
But esteemed Academy Award nominated character actress and film director, Margot Robbie, if it's unlikely that Hollywood actress Sydney Sweeney said this... wouldn't it be just as unlikely that Margot Robbie would be here? Adding her own comment?
... are you projecting? Is there something you want to tell us esteemed Academy Award nominated character actress and film director Margot Robbie?
Why is anyone using X in 2024?
I use X because Cinnamon on Wayland has no option to change the keyboard layout
Wayland really doesn't like RDP/remote access, so X is the only way to go if you want that to work properly.
I tried it for a moment, made games stutter like hell, switched back. I know I need to go in and figure it out at some point, but it's hard to muster the energy when X, for the most part, works fine.
From what I've seen, it probably has to do with my Nvidia GPU.
Imagine rewring history
History is written by the squashers.
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.
I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It's good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don't know how to edit them.
Honestly, I'm pretty sure 99.9% of git users never really bother with the git history in any way that would be hindered by merging.
Git has a ton of powerful features, but for most projects they don't matter at all. You want a distributed consensus, that's it. Bothering yourself with all those advanced features and trying to learn some esoteric commands is frankly just overhead. Yes, you can solve great problems with them, but these problems almost never occur, and if they do, using the stupid tools is faster overall.
Please for the love of god don't use merge, especially in a crowded repository. Don't be me and suffer the consequences. I mistakenly mention every person with a commit between the time I created the branch until current master.
That was you! I remember this.
AAAH NOT LIKE THIS
There's 102 people mentioned in that commit and two of them happen to meet in the comments of a meme thread on Lemmy of all places. I love the Internet.
Okay this is the second time I've seen Sydney Sweeney referenced in a meme in less than half a day. I had never heard of her before. Who is she, and why is she suddenly attracting so much meme attention?
She's an ~~Australian~~ American actress who blew up last year (she was in euphoria I think?), expect to see her in a ton of upcoming blockbusters.
You are probably thinking of another talented blonde Australian actress.
She is from Spokane Washington not Australia. She got a lot of recognition for her role in Euphoria and is blowing up a bit right now because she is a young, attractive, talented actress.
I've been using merge, and I hate that I don't even know what rebase really does
Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.
Merge is taking all the code from the master branch and combining it with the task branch, resulting in a commit for just the merge itself.
Rebase is "re-basing" where your task branch was created from off the master branch. It essentially takes all the commits from master that happened since you branched, REWRITES THE HISTORY of your task branch by inserting those master branch commits before all your existing commits, and effectively makes your task branch look like it was branched yesterday instead of like 4 weeks ago. You changed where your task branch originated on the master. You moved its base.
Atlassian does a fantastic writeup on this.
Did she just tell people up git good?
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 keeps the original timeline. Your commits go in along with anything else that happened relative to the branch you based your work off (probably main). This generates a merge commit.
Rebase will replay all the commits that happened while you were doing your work before your commits happen, and then put yours at the HEAD, so that they are the most recent commits. You have to mitigate any conflicts that impact the same files as these commits are replayed, if any conflicts arise. These are resolved the same way any merge conflict is. There is no frivolous merge commit in this scenario.
TlDR; End result, everything that happened to the branch minus your work, happens. Then your stuff happens after. Much tidy and clean.
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.
I feel the opposite, but for similar logic? Merge is the one that is cluttered up with other merges.
With rebase you get A->B->C for the main branch, and D->E->F for the patch branch, and when submitting to main you get a nice A->B->C->D->E->F and you can find your faulty commit in the D->E->F section.
For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B'->E->F->C->C' where the ones with the apostrophe are merge commits. And worse, in a git lot there is no clear "D E F" so you don't actually know if A, D or B came from the feature branch, you just know a branch was merged at commit B'. You'd have to try to demangle it by looking at authors and dates.
The final code ought to look the same, but now if you're debugging you can't separate the feature patch from the main path code to see which part was at fault. I always rebase because it's equivalent to checking out the latest changes and re-branching so I'm never behind and the patch is always a unique set of commits.
I used to only merge. Now I rebase. The repo is set up to require squash and rebase when going to main.
All the garbage "spelled thing wrong" and "ran formatter" commits go away. Main is clean and linear.
I'll go one further: use git rebase --interactive
I remember learning about how to use this back in the day and what a game changer it was for my workflow.
Today I like to do all of the commits as I’m working. Maybe dozens or more as I chug along, marking off waypoints rather than logging actual changes. When I’m done a quick interactive rebase cleans up the history to meaningful commits quite nicely.
The fun part is that I will work with people sometimes who both swear that “rewriting history” is evil and should never be done, but also tell me how useful my commit logs are and want to know how I take such good notes as I go.
Argh. I hate that argument.
Yes - "Rewriting history" is a Bad Thing - but o argue that's only on 'main' (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.
If you rewrite main's history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don't be that guy.
Before you push though... rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.
I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.
Anyway. Good on you; Keep the faith; etc etc. :)