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.
this post was submitted on 04 Apr 2024
218 points (97.4% liked)
Programmer Humor
19618 readers
783 users here now
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.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
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.
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.
load more comments
(1 replies)
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."
- 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.
load more comments
(1 replies)
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?
load more comments
(4 replies)
ITT: people who have no idea how rebasing works.
Skill issue tbh
No doubt. git rebase is 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.
load more comments
(10 replies)
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.
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
load more comments
(6 replies)
load more comments
(5 replies)
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!)
load more comments
(3 replies)
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 - F
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.
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.
load more comments
(3 replies)
load more comments
(2 replies)
Why is anyone using X in 2024?
I do, I have yet to switch to Wayland
Shit, I unironically thought they were talking about this, and I unironically haven’t switched because Barrier is broken on Wayland
load more comments
(10 replies)
i like to create ten different checkouts of main, rebase them all slightly differently and then no fast forward merge them all back into each other
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.
load more comments
(22 replies)
Rebase feature branch, merge commit into main (NO SQUASH).
make the commit message be "we’ve fixed bugs and improved performance. to experience the newest features and improvements, checkout the latest version of the branch."
load more comments
(1 replies)
view more: next ›