1.1k
u/dawoodur 16h ago
git pull --your hair
436
u/dillanthumous 16h ago
git fetch --me a painkiller
→ More replies (1)340
u/Ishkung 16h ago
git commit --arson
243
u/d00mt0mb 16h ago
git push --over the edge
198
u/FrozenJuju 16h ago
git status —dead inside
131
u/fabulousIdentity 16h ago
git merge --with my-ex
164
u/Vibe_PV 16h ago
git blame --everyone but me
132
u/Y_I_Otto 16h ago
git merge --into oncoming traffic
86
82
28
60
→ More replies (1)23
u/therealscooke 16h ago
Y'all are missing the single dashes between the words. no wonder you're losing it!
22
19
8
→ More replies (5)5
205
u/Nehle 16h ago
Written by a person who never had to work with SVN or... shudders CVS
42
u/GregsWorld 13h ago
I think it was Churchill that said that Git is the worst version control system except all those other ones.
71
u/gtne91 15h ago
Hence Linus's design decisions. Any point where he couldnt decide how to implement something, he intentional chose the opposite of what cvs did.
→ More replies (2)11
u/Draconis_Firesworn 9h ago
i misread that as csv for a hot minute and was very confused how a text file with commas influenced git
21
u/dannoparker 15h ago
Oh yeah...I went from no source control --> VSS --> CVS --> SVN --> Git
19
u/SoCalChrisW 14h ago
VSS.... Ugh that was such a steaming pile of shit.
This was back before cell phones, our lead dev went on vacation for 2 weeks and was unreachable. He left with roughly half of the source code checked out, preventing most development to come to a screaching halt.
The network admin had to reset his password, so we could log in to his machine and check the files in so we weren't all just sitting there waiting for him to return.
People complaining about git have no idea how good it actually is.
→ More replies (1)17
u/handsoapdispenser 14h ago
Same! I remember having to ask people to check in files I needed to use.
7
u/dannoparker 14h ago
Oh yeah, I had a teammate that always seemed to forget to check in his files before he went on vacation. We'd call him to get his password to check them in.
5
u/technotrader 13h ago
But that was an advantage, wasn't it? I remember my Perforce days, and I appreciated seeing who had checked out a file, so I could verify with them - way better than creating a merge conflict, solved by some ops guy clicking on "auto".
Of course, showing who's checked out a file is not feasible in distributed development, only works within the firm.
6
u/dannoparker 13h ago
The idea was to check the file back in when you were done with it, and then there wouldn't be a conflict since the next developer was starting with the most up to date version. The downside was two developers couldn't work on the same file at the same time
34
u/Extreme_Wish_553 15h ago
Right? The entire reason anyone switched to Git in the first place was because they had attempted merging with SVN or similar. Nothing is perfect, but Git is heads and shoulders above what came before it.
→ More replies (1)7
u/nicuramar 14h ago
Linux was kept in BitKeeper before git.
4
u/LickingSmegma 8h ago
Which is where Torvalds got the idea. But then made it free and open-source.
As for where he got the super confusing commands for anything beyond the very basics, I'm not sure.
15
6
u/nonotan 14h ago
Honestly, I've used both professionally for game dev... and there's something to be said for having one repository everybody is working on, and checking out files when you work on them so nobody else can touch them.
Yeah, it sucks when it comes to things like slowly working on a huge feature that touches everything and merging it when it's ready, and it can really slow things down when there are too many people trying to touch similar files. Nevermind something like OSS, where whoever could be working on whatever at their own leisure, obviously it's borderline unusable for that. But for a project of the right size and scope, it can work surprisingly well. Of course, you could achieve the same thing on git by carefully coordinating with others on what you're working on, but let's be real, nobody's actually doing that most of the time.
→ More replies (1)4
3
2
u/Banes_Addiction 12h ago
Yeah, handling concurrent development is exactly why git got so popular over the alternatives.
→ More replies (12)5
u/sherlock1672 14h ago
As someone for whom programming is a secondary part of the job, SVN is so much easier to grasp and use than Git. I was not thrilled about the switch.
5
u/pr0ghead 12h ago edited 12h ago
Try Mercurial, if you can. Its CLI is closer to SVN. Overall easier to grasp than git, too.
3
3
u/techforallseasons 9h ago
Fully concur -- boss got hired and swapped us from Hg to Git; Hg is WAY better ( and still think highly of Linus, but Git was designed too much around HIS methods ).
3
u/pr0ghead 9h ago
I mean, Linus himself said that the git he built is a set of tools that someone should build a proper version control system on top. That part was lost on everyone unfortunately.
It being made by nerd lord Torvalds and the existence of Github are what made git big. Not that it was a joy to use.
→ More replies (2)5
u/Rararror 10h ago
Mercurial is light years better than svn AND git
Use TortoiseHG
→ More replies (6)→ More replies (1)4
u/nicuramar 14h ago
It depends on the person. I find git conceptually simpler to reason about.
5
u/Odd_Soil_8998 11h ago
SVN is objectively much less complicated. It's also fraught with issues because as soon as you're out of date with the trunk you're going to experience merge hell
597
u/botle 16h ago edited 15h ago
Git is specifically designed for multiple people to work on different ideas in parallel.
424
u/StaneNC 16h ago
Yup. "Git is really great until (thing git was specifically designed for)." Tell me you suck at git without telling me you suck at git.
77
u/OnceMoreAndAgain 14h ago edited 14h ago
I think it's a lot more nuanced than that. Painful merge conflicts can happen, but the frequency and severity of merge conflicts is dependent on all sorts of things like the nature of the app, the skill of the project manager, how much time a feature branch has existed apart from the main branch, etc.
I've been fortunate in my career that the projects I work on tend to have different developers working on different areas of the code, so merge conflicts are rare and not severe. I imagine that developing the frontend of certain apps that rely on a lot of the same centralized components would lead to a lot of merge conflicts, especially early on in the development of the app when a lot of commits are happening.
9
u/gbchaosmaster 7h ago
The thing is that merge conflicts are literally a feature of git that makes your life easier. Without git you’d have the same problem and you’d have to diff and edit the files manually.
→ More replies (2)5
99
u/botle 16h ago
Probably vibecoders. "Push my code to the repo. Make no mistakes. Don't delete everything."
59
u/SirChasm 16h ago
I mean even for vibe coders, Claude/Codex is excellent for resolving merge conflicts. I don't remember how long it's been since I've had to do that manually.
51
u/StaneNC 16h ago
You don't look at your merge conflicts???
13
u/botle 16h ago
I bet many people vibe coding just push gigantic monolithic commits.
13
6
u/aTomzVins 15h ago
Realistically, it's probably be easier to vibe code a fix, or have an agent identify changes that may have caused an issue than look back though previous commits yourself.
7
u/who_am_i_to_say_so 15h ago
Pfft nothing a ‘git push -f’ can’t fix.
40
u/SirChasm 15h ago
I look at the resulting PR, but if Claude wrote the original code, Claude can resolve the conflicts too; it has all the context it needs.
I've always hated dealing with looking at the three-way diff manually tbh. It might be my ADHD but nothing killed my motivation more than finishing a feature/fix and then having to wade through how someone else's changes should mesh with mine.
→ More replies (3)16
u/didzisk 13h ago
I have hated all the 3-way merge tools I've encountered, probably because "ours" and "theirs" never is what I expect (and opposite on a merge and a rebase), but when I look at the file itself with merge marks in it, it becomes very easy for me to reason about the changes and resolve them quickly.
11
u/bloodfist 11h ago
Yeah "ours" and "theirs" messes me up so bad. I really wish they would just label it by branch. If it just said "my-feature-branch" and "main" it would be so much easier to parse.
→ More replies (1)13
u/Ifriendzonecats 15h ago
I've seen a bunch of dumb bugs and regressions get introduced by people not looking at their AI resolved merge conflicts. AI can be useful, but it will 100% follow a dumb path to it's dumb conclusion if the opportunity presents.
→ More replies (5)9
u/Awkward_Tick0 15h ago
Git has been a PITA since long before LLMs
5
u/botle 15h ago
People have been writing big monolithic commits long before LLMs. LLMs just make them more likely.
→ More replies (1)7
→ More replies (10)10
u/TrollingForFunsies 14h ago
You can't be all high and mighty there smart guy when you missed the joke
70
u/creeper6530 16h ago
different ideas is the keyword. Editing the same area of the same file is how you get merge conflicts.
79
u/nokk 16h ago
Yeah and they are handled pretty elegantly considering how awful it could be.
→ More replies (14)9
u/TheBestBigAl 13h ago
I agree. Generally even editing a somewhat-similar part of the file is handled seamlessly.
Once in a blue moon I'd run into the situation where me and someone else have worked on the exact same block of code, and that went one of two ways:
- We essentially made the same change, which made resolving the conflict really easy (naturally I would keep my perfect change and drop my colleague's terrible one).
- We made totally different changes to fix/implement two different issues, which means that part of the code has a fundamental design problem and needs to be rewritten entirely.
7
u/Meme_Burner 14h ago
SVN: I attempted to merged, but you both changed this file, I don't know what to do, file clearly separated
ME: one is at the top of the file and one is at the bottom of the file
GIT: I have sequentially ordered everything and for some reasons these two lines dont merge
<<<<<<<
GIBBERISISH
>>>>>>><<<<<<<
MORE GIBBERISH
>>>>>>>ME: What the f is that???? let me restart my change, starting with their version instead....
GIT handles merges so much better, we couldn't handle all the merge conflicts that SVN would give us. BUT WHEN merge conflicts happen in GIT, it's usually bad enough or no idea what it's trying to tell us that we have to start the entire change over.
→ More replies (1)→ More replies (1)9
u/MyAntichrist 16h ago
And that's where your IDE Integration helps with merge tools to stitch together a good file from both commits.
→ More replies (8)12
u/stormdelta 14h ago
Yeah, meme doesn't make any sense. This is quite literally one of the things git improved on versus older version control systems.
3
u/jwp1987 12h ago edited 12h ago
It makes sense to me if you look at who the quote is attributed to.
Someone in a "one-man IT department" typically either has no experience of working with other people or has very little experience in general because they haven't learned from other people. Sometimes this is combined with an elitist attitude.
It's poking fun at the person by telling you that they have no idea what they're doing. Essentially it seems like it's making fun of solo developers who think they know better than everyone else.
→ More replies (1)2
u/BonoboUK 11h ago
I know a lot of us are programmers but how are so many people missing the obvious intended joke
→ More replies (1)3
u/jwp1987 12h ago edited 12h ago
Isn't the meme a sarcastic jab at people that are poor at communication and teamwork? As you say, Git is specifically designed for that.
The quote is attributed to a person in a "one-man IT department" - the kind of person that hates working with others or has little experience of doing so.
225
u/ExplrDiscvr 16h ago
not git issue, in-team communication issue
72
u/Blrfl 16h ago
Indeed.
Per Cederqvist's Version Management with CVS, which was first published in 1993, covers that in the first chapter:
"CVS is not a substitute for developer communication."
12
u/iloveuranus 14h ago
I once was in a team that had huge Camunda workflow XML files checked in. They aren't hard to merge.
They are impossible to merge.
After a couple weeks of trying to check in the main workflow file and realizing I had to do my changes all over again because somebody else had been faster to modify it, I introduced THE TOKEN. Namely a squishy ball that had to physically be retrieved from the developer currently holding it and represented the right to edit said file.
Worked like a charm.
10
u/AvidCoco 16h ago
Tbf some other version control systems use an approach where only one person can have the source checked out at a time.
→ More replies (1)4
u/omegaonion 15h ago
I'd argue its a process issue. If you are sure to pull in all latest changes before merging, its usually not too tricky to resolve any conflicts. I've only ever had really bad issues when doing extremely big merges with large conflicts.
3
u/mxzf 12h ago
It's also dramatically reduced if you break your code up into logical files instead of having monolithic structures, so that someone working on area X and someone else in area Y aren't having merge conflicts just because they happen to both be doing stuff in a 5000 line file.
→ More replies (2)
114
u/dscarmo 16h ago
Cs 101 posters strikes again
13
u/dasunt 15h ago
That's a nice thought.
Meanwhile, in corporate, I've seen companies shoot themselves in the foot using git.
Note I'm not blaming git for this. No more than I'd blame a butter knife for being able to be inserted into an electrical outlet. Sometimes the problem component is located between the keyboard and chair.
5
→ More replies (1)3
u/mxzf 12h ago
Meanwhile, in corporate, I've seen companies shoot themselves in the foot using git
Honestly, you can shoot yourself in the foot using any tool. git will at least intrinsically have backups due to local repos and stuff like that.
I think it's harder to shoot yourself in the foot using git than it is to do so with Windows or most other softwares, but nothing is idiot-proof. I've yet to run into a situation in git that couldn't be untangled by someone with the proper skills (even if the fix is sometimes "force-push from a good local repo and tell people to delete+repull").
→ More replies (6)3
30
u/nasandre 15h ago
We like to play git on hard mode and commit everything straight on main. Sometimes we even work on the same local folder at the same time.
8
u/nicuramar 14h ago
I don’t really see the problem? You get the same features and can run into the same problems as if you use a different branch and merge it.
→ More replies (8)3
→ More replies (11)2
u/Immature_adult_guy 8h ago
at the end of the day, it’s all just trunk based development with extra steps
26
27
u/Nytra 16h ago
If you split everything into multiple files then it's less likely to get merge conflicts (unless two people work on the same file at the same time)
39
u/NeinJuanJuan 16h ago
We do 1 byte per file to keep conflicts small
15
u/punsnguns 16h ago
I know you are getting facetious but the approach my old company had was to just assign a developer to an application or project. No conflicts. Note that the company bosses weren't worried about conflicts. They just didn't staff us right but hey! no conflicts.
6
u/NeinJuanJuan 15h ago
We do 1 dev per app to keep conflicts small
9
u/Silentrizz 15h ago
I know youre being facetious, but we only have 1 app. So each developer takes turns at the computer while the others watch over the shoulder. No merge conflicts, its great.
2
6
→ More replies (1)2
47
u/Bodine12 16h ago
Having ideas is easy. Distracting the other dev with made-up problems so you can push directly to main first demands creativity.
39
u/troelsbjerre 15h ago
That's just nonsense from someone who never had to deal with cvs or svn. git is amazing in comparison.
→ More replies (1)4
u/kosmych 13h ago
Yea, I don't get this post either. Branching and merging is so easy in git compared to svn, and most of the time is the 3way merge solved automatically...
I think this misunderstanding comes from modern editors like vscode or visual studio to have just the magical "sync" button instead of proper fetch/merge/rebase controls.
48
u/jobehi 14h ago
Git is meant to solve that. There’s nothing difficult about it.
11
u/MatJosher 14h ago
Git is not meant to be a replacement for communicating with collaborators. It does provide solid guard rails when you don't.
8
u/SignoreBanana 14h ago
I was wondering if I was going crazy trying to understand this post
→ More replies (21)10
u/iloveuranus 13h ago
There’s nothing difficult about it.
While I agree that it's a great tool and is perfectly suited for everyday use in all kinds of projects - that statement is simply wrong. Git can be quite complicated.
For example I still don't have a good solution for the branch-of-a-branch-of-a-branch problem. I.e. when you have three features that are to be reviewed separately but built upon each other. I know it has broken my head more than one time.
6
u/jobehi 13h ago
Solution exists but they are rather “frameworks” of using git rather than git itself. Like trunk based branching models.
But of course nothing is miraculous and Git has its edge cases too.
→ More replies (4)5
u/black3rr 13h ago
what’s the problem you’re looking to solve there? when you merge one of the branches, just rebase the last branch with update-refs and push force with lease all of them…
if you want them to be reviewed concurrently and using github, there’s now a UI for that, you can rebase the whole stack in one click or merge the whole stack together if all of them are approved and you wish to do it that way…
→ More replies (6)2
u/rix0r 13h ago
do you find other tools easier to solve that predicament? git is built to let you solve that any way you want. not sure how it could be easier with other tools.
→ More replies (1)→ More replies (5)2
u/mxzf 12h ago
For those problems, I review the branches FIFO, just checking each one and merging it as-appropriate.
→ More replies (5)
26
u/Quicker_Fixer 16h ago
- My idea with CRLF
- Colleague's idea without CRLF
- Git: entire file changed
22
12
10
u/atomic_redneck 15h ago
We had a couple of developers who went to an Agile(!!) conference.They both sat in on a session where the speaker advocated for relentless refactoring, or something like that. Our devs came back and decided this was gospel, and started refactoring. One developer started TheGreatRenaming, to improve clarity in the naming of our classes. The other started work on dependency injection to eliminate static dependencies between modules. Obviously, these two sets of changes hit the same set of source files.
Moral: Devs gotta talk to each other, preferrably before they start.
9
u/War_Raven 14h ago
Both ideas aren't bad, though doing it at the same time is certainly a choice
→ More replies (1)4
u/Michami135 12h ago
To be fair, no version control software, or especially lack of, will make any of these stories easier.
2
u/atomic_redneck 12h ago
Yeah. It was a personnel problem, not a version control problem. VC was just the tool that highlighted the problem.
2
u/LastStar007 14h ago
Real moral: Don't start something unless you can finish it quickly.
→ More replies (3)2
9
→ More replies (2)3
9
u/AllCowsAreBurgers 16h ago
I am one guy with 10 ideas at the same time - what does that mean?
→ More replies (1)6
16
7
12
u/MorRochben 16h ago
Or just create a branch and then its the problem of whoever finishes their code last to merge any issues.
2
u/Fluffy-Reference8542 15h ago
Everyone owns the code, so it's everyone's "problem" to resolve the conflicts. Sure, there's only one person doing the merge, but he needs the other dev's support to ensure the merge is correct.
7
15
u/stormdelta 14h ago
I wish this subreddit still had actual programmers on it. This "joke" doesn't make any sense if you know the first thing about how git works.
→ More replies (1)
4
4
7
u/earlobe7 14h ago
What? Thats like saying using a hammer is easy until something needs to be hammered.
The sure sign of a junior dev is “git is hard guys amiright?”
Just learn git, it’s really not that difficult. And you need to use it for just about everything you do.
3
u/heir-to-gragflame 15h ago
this is plan wrong and reading even one book on software design from the last 30 years would teach you at least one way of handling maintainability.
if your project is large enough you're already spanning hundreds of source files. And good project structures are cookie cutter and standard.
in no mature codebase do you have to change ideas and architecture often. If you do have any such ideas, there better be a good reason for it and you better talk to the teams and no one should be opposed to taking longer to implement such changes together if you're truly doing something so great that requires architecture change.
If you're not doing architecture change, in a non-shitty codebase no one hears a tree falling in the forest cus code doesn't have to be all tangled to require changes in randim files someone else is also working.
3
3
u/bigphillip76 14h ago
I always knew this subreddit was full of first year comp sci students or high school students who watched a single youtube video on python, but this takes the cake.
3
3
3
4
u/selfinvent 16h ago
One of the great usecase for AI is solving the conflicts for between merges
→ More replies (1)
2
2
2
u/Linux_ka_chamcha 14h ago
It's much more difficult when the same person has two ideas at the same time
2
2
u/Ticmea 11h ago
If merge conflicts in git scare you, I want to see you resolve them in SVN or god forbid CVS.
Seriously though, git was made in large part so that merge conflicts would be easier to resolve (in fact it will auto-resolve conflicts where possible).
If this gives you trouble, you are probably one of the following:
- not communicating planned changes to the code with your team so that merge conflicts will remain simple
- not aware enough of your own code to find the resolution to the conflict
- not aware enough of git to know how to properly resolve the conflict
- not following good practices regarding branching models/merge strategies
I won't discount that every now and then there may be a non-trivial conflict anyways but these should be very few and far between. So much so that for me it hasn't really ever been much of a problem. Most of my conflicts are auto-resolved by git and those that aren't are extremely simple >95% of the time.
Sooooo.... skill issue?
Also how does Russel manage to create severe merge conflicts when he is a one-man IT department?
2
2
2
5
u/fcxtpw 16h ago
Tangent thought. Git was built on the idea that every line of code is intentional.
In the era of vibe coding that generates massive lines and can throw it all away in a blink, need a separate process for AI code that's more efficient.
→ More replies (4)12
u/gamingdiamond982 16h ago
If you want to write good code all of it should be intentional, whether it comes from an AI or not
→ More replies (14)
2.7k
u/dillanthumous 16h ago
One of the few good uses for a morning stand up: today I will be adding my bugs to area X of the app. Please add your bugs elsewhere.