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.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.
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.”
- 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.
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?
I think this is a fake quote that somebody made up for an Internet comedy bit
You can tell by the pixels
No, the tweet is real. Just not the quote.
Why is anyone using X in 2024?
I do, I have yet to switch to Wayland
It’s called Twitter now, by conservation of names. /s
You didn’t hear of wayland.social?
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.
Odd, when i switched to Wayland the stuttering stopped! Also on Nvidia
On nvidia, it definitely feels much smoother, but some GPU accelerated programs like games become flickery, i think it’s an xwayland issue
Depends on a few things with your setup: age of your GPU, the resolution/refresh rate of your monitor. I think even the choice of DP/HDMI can have an impact too
Wayland really doesn’t like RDP/remote access, so X is the only way to go if you want that to work properly.
I actually never had an issue on my wayland system. I used remmina for rdp but never had an issue.
Because my new intel integrated graphics cause Wayland to run like a slideshow.
because some of the hardware I use is too old to run Wayland
Because their name is Elon Musk.
deleted by creator
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.
Why would you want to edit your commit history? When I need to look at it for some reason, I want to see what actually happened, not a fictional story.
Because when debugging, you typically don’t care about the details of
wip,some more stuff,Merge remote-tracking branch 'origin/master',almost working,Merge remote-tracking branch 'origin/master',fix some testsetc. and would rather follow logical steps being taken in order with descriptive messages such ascomponent: refactor xyz in preparation for feature,component: add do_foo(),component: implement feature using do_foo()etc.You can have both. I’ll get to that later. But first, let me explain why edited history is useful.
Unedited histories are very chaotic and often contains errors, commits with partial features, abandoned code, reverted code, out-of-sequence code, etc. These are useful in preserving the actual progress of your own thought. But such histories are a nightmare to review. Commits should be complete (a single commit contains a full feature) and in proper order. If you’re a reviewer, you also wouldn’t want to waste time reviewing someone else’s mistakes, experiments, reverted code, etc. Self-complete commits also have another advantage - users can choose to omit an entire feature by omitting a commit.
Now the part about having both - the unedited and carefully crafted history. Rebasing doesn’t erase the original branch. You can preserve it by creating a new branch. Or, you can recover it from reflog. I use it to preserve the original development history. Then I submit the edited/crafted history/branch upstream.
Git-
illeterateilliterateAh thanks.
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
Could have been worse. I mean, like, imagine of you were using like CVS and you put a watch on the root! Haha and then like every trivial commit in the repo caused everyone to in the entire org to get an email and it crashed the email servers.
Like who’d even DO that?! Though, I bet if you met that guy he’d be ok. Like not a jerk, and pretty sorry for all those emails. A cool guy.
Merge is not the issue here, rebase would do the same.
really? how come? I thought they are mentioned because of the diffs if compared to master, which merge basically just… merge on top of my branch (?)
They were mentioned because a file they are the code owner of was modified in the PR.
The modifications came from another branch which you accidentally(?) merged into yours. The problem is that those commits weren’t in master yet, so GH considers them to be part of the changeset of your branch. If they were in master already, GH would only consider the merge commit itself part of the change set and it does not contain any changes itself (unless you resolved a conflict).
If you had rebased atop of the other branch, you would have still had the commits of the other branch in your changeset; it’d be as if you tried to merge the other branch into master + your changes.
Just for the record, I think you’re conflating git and GitHub. They are not the same thing, even if GH would like you to think so.
I am not. Read the context mate.
You sent over twenty-two thousand notifications lmao.
And then the bot added about as many tags to the PR.
ITT: people who have no idea how rebasing works.
Rebasing is for noobs.
git reset head~42 git push -fHoly shit
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.
Thanks for the explanation. It makes sense. To my untrained eyes, it feels like both merge and rebase have their use. I will try to keep that in mind.
100% they do. Rebase is an everyday thing, merge is for PRs (for me anyway). Or merges are for regular branches if you roll that way. The only wrong answer is the one that causes you to lose commits and have to use
reflog, cos…well, then you done messed up now son… (but even then hope lives on!)Yes. They do. A lot of people will use vacuous terms like “clean history” when arguing for one over the other. In my opinion, most repositories have larger problems than rebase versus merge. Like commit messages.
Also, remember, even if your team/repository prefers merges over rebases for getting changes into the main branch, that doesn’t mean you shouldn’t be using rebase locally for various things.
You nailed it with the critique of commit messages. We use gitmoji to convey at-a-glance topic for commits and otherwise adhere to Tim Pope’s school of getting to the point
I must have read that blog post in the past because that’s exactly the style I use. Much of it is standard though.
One MAJOR pet peeve of mine (and I admit it is just an opinion either way) is when people use lower case letters for the first line of the commit message. They typically argue that it is a sentence fragment so shouldn’t be capitalized. My counter is that the start of sentences, even fragmented ones, should be capitalized. Also, and more relevant, is that I view the first line of the commit more like the title of something than a sentence. So I use the Wikipedia style of capitalizing.
Gitmoji?
Quasi parallel reply to your other post, this would kind of echo the want for a capital letter at the start of the commit message. Icon indicates overall topic nature of commits.
Lets say I am adding a database migration and my commit is the migration file and the schema. My commit message might be:
🗃️ Add notes to Users tableSo anyone looking at the eventual pr will see the icon and know that this bunch of work will affect db without all that tedious “reading the code” part of the review, or for team members who didn’t participate in reviews.
I was initially hesitant to adopt it but I have very reasonable, younger team mates for whom emojis are part of the standard vocabulary. I gradually came to appreciate and value the ability to convey more context in my commits this way. I’m still guilty of the occasionally overusing:
♻️ Fix the thingtype messages when I’m lazy; doesn’t fix that bad habit, but I’m generally much happier reading mine or someone else’s PR commit summary with this extra bit of context added.
I looked at it and there’s a lot of them!
I see things like adding dependencies but I would add the dependency along with the code that’s using it so I have that context. Is the Gitmoji way to break your commits up so that it matches a single category?
How would rebasing my own branch work? Do I rebase the main into my branch, or make a copy of the main branch and then rebase? I have trouble grasping how that would work.
You’re still rebasing your branch onto main (or whatever you originally branched it off of), but you aren’t then doing a fast forward merge of main to your branch.
The terminology gets weird. When people say “merge versus rebase” they really mean it in the context of brining changes into main. You (or the remote repository) cannot do this without a merge. People usually mean “merge commit versus rebase with fast forward merge”
Yeah I was confused because you are right, merge is usually refered as the git merge and then git commit.
It makes sense. Thanks for the clarification
Here’s an example
Say I work on authentication under
feature/authMonday and get some done. Tuesday an urgent feature request for some logging work comes in and I complete it onfeature/loggingand merge clean to main. To make sure all my code from Monday will work, I will then switch tofeature/authand thengit pull --rebase origin main. Now my auth commits start after the merge commit from the logging pr.Thanks for the example. Rebase use is clearer now.
Yes. My rule of thumb is that generally rebasing is the better approach, in part because if your commit history is relatively clean then it is easier to merge in changes one commit at a time than all at once. However, sometimes so much has changed that replaying your commits puts you in the position of having to solve so many problems that it is more trouble than it is worth, in which case you should feel no qualms about aborting the rebase (
git rebase --abort) and using a merge instead.I have the bad habit of leaving checkpoints everywhere because of merge squash that I am trying to fix. I think that forcing myself to rebase would help get rid of that habit. And the good thing is that I am the sole FW dev at work, so I can do whatever I want with the repos.
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.
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.
Your notation does not make sense. You’re representing a multi-dimensional thing in one dimension. Of course it’s a mess if you do that.
Your example is also missing a crucial fact required when reasoning about merges: The merge base.
Typically a branch is “branched off” from some commit M. D’s and A’s parent would be M (though there could be any amount of commits between A and M). Since A is “on the main branch”, you can conclude that D is part of a “patch branch”. It’s quite clear if you don’t omit this fact.I also don’t understand why your example would have multiple merges.
Here’s my example of a main branch with a patch branch; in 2D because merges can’t properly be represented in one dimension:
M - A - B - C - C' \ / D - E - FThe 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.
If you use a feature branch workflow and your main branch is merged into, you typically want to use first-parent bisects. They’re much faster too.
You’re right, I’m not representing the merge correctly. I was thinking of having multiple merges because for a long running patch branch you might merge main into the patch branch several times before merging the patch branch into main.
I’m so used to rebasing I forgot there’s tools that correctly show all the branching and merges and things.
Idk, I just like rebase’s behavior over merge.
The thing is, you can get your cake and eat it too. Rebase your feature branches while in development and then merge them to the main branch when they’re done.
👏 Super duper this is the way. No notes!
I would advocate for using each tool, where it makes sense, to achieve a more intelligible graph. This is what I’ve been moving towards on my personal projects (am solo). I imagine with any moderately complex group project it becomes very difficult to keep things neat.
In order of expected usage frequency:
- Rebase: everything that’s not 2 or 3. keep main and feature lines clean.
- Merge: ideally, merge should only be used to bring feature branches into main at stable sequence points.
- Squash: only use squash to remove history that truly is useless. (creating a bug on a feature branch and then solving it two commits later prior to merge).
History should be viewable from log --all --decorate --oneline --graph; not buried in squash commits.
Folks should make sure the final series of commits in pull requests have atomic changes and that each individual commit works and builds successfully alone. Things like fixup commits with auto squash rebase. THIS WAY you can still narrow it down to one commit regardless of the approach.
I’ll go one further: use
git rebase --interactiveI 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.
- review is easier since concerns aren’t mixed
- If a commit needs to be reverted it limits the collateral damage
- history is easier to follow because the commits tell a story
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. :)
The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.
Even better, master creating fixup and squash commits and maintain logical commits as you work with
git rebase -i --autosquash
This is really the only sane way to do it. I have run into some wonkyness with the commit history of the target branch commits not resembling
git log, but that’s usually for commits outside of what I’m trying to merge.Edit: squashing commits down this way also helps reduce problems with replaying commit history on the actual rebase. In most cases you don’t need all your “microcommits” in the history, and fewer commits just takes less time to reconcile.
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.
Squash and rebase or squash or rebase?
…and? You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up into a single “Add endpoint to allow users to set their blah blah” comment with a nice extended description.
You then rebase so you have a nice linear history with no weird merge commits hanging around.
You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up
The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.
Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.
Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that “rebasing”? Or is that just squashing? Because it seems that achieves the same thing you’re talking about.
There’s two options in the green button on a pr. One is squash and merge, the other is squash and rebase.
Squashing makes one commit out of many. You should IMO always do this when putting your work on a shared branch
Rebase takes your commit(s) and sticks them on the end.
Merge does something else I don’t understand as well, and makes a merge commit.
Also there was an earthquake in NYC when I was writing this. We may have angered the gods.
You should IMO always do this when putting your work on a shared branch
No. You should never squash as a rule unless your entire team can’t be bothered to use git correctly and in that case it’s a workaround for that problem, not a generally good policy.
Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.Rebase “merges” are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn’t. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.
I don’t want to see a dozen commits of “ran isort” “forgot to commit this file lol” quality.
Do you?
Having the finished feature bundled into one commit is nice. I wouldn’t call it stupid at all.
Note that I didn’t say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.
Lmao I’m in the NYC area and my whole house shook. I’m right there with you. Thanks for the explanation!
git merge --no-ffRebase feature branch, merge commit into
main(NO SQUASH).Heres my based af workflow:
git checkout -b feature-branch
rebase on top of dev whilst working locally
git rebase origin/dev-branch && git push -f
if i need to fix conflicts with dev-branch during a PR
git merge origin/dev
Fuck a merge commit! Rebase ervray day bay bayyy.
Anyone mind explaining to me how
git rebaseis worth the effort?git mergehas it’s own issues but I just don’t see any benefit to rebase over it.Well, rebase allows you to resolve the same conflict ten times in a row instead of doing it once. How cool is that?
Nope, you just need to do it once: https://git-scm.com/book/en/v2/Git-Tools-Rerere.
Why would I ruin all the fun?
Squash your branch first
Doesn’t this defeat the purpose, may as well merge then no?
Do not merge your unfinished stuff into main.
I don’t like merging main into my branch because I don’t understand git, and I feel like that can make a confusing history.
The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.
I personally prefer “git off my lawn”
Ah, yes, the good old
git off --my lawncommand.
