@@nehemiah6280 So what if you are pushing daily? Are you pushing into the main branch? The issue the OP talks about is you being slow and falling behind the trunk and unless you are pushing daily to trunk (which is retarded) there's no way your daily pushes make anything better. If anything it tells me you are one-man-show.
I started working at Meta (called Facebook then) in 2014. We used Git then. The sauce at the time was that we switched to Mercurial because although neither Git nor Mercurial could scale to our needs, there was a lot more friction upstreaming our scale patches to Git than to Mercurial. And we didn't want to maintain our own fork.
The stacking stuff is unrelated to git vs hg, though. We used stacking for both. We actually have a wrapper around the source control stuff anyway, so many/most people didn't even notice when it switched.
Errr putting ketchup on git aint gonna work. Sauce?? If you worked as a coder on any level and still dont know the diff between Source and Sause i can see why you dont still work there
Git is probably confusing due to a lack of context around the problems its trying to solve. The entry level user is just trying to check out and save progress. The only tools they need is to be able to create backups and download files. Then they're introduced to a complicated tree system and CLI designed to solve a series of problems relating to group development over time and space with steps like staging and branching.
GIT is designed for OSS (specifically Linux kernel) work. It's fantastic at that, providing complex branch management, SSH key signoffs, and a ton of other stuff that allows it to float out in the public space. It's a shitty tool for corporate work. Mercurial is way simpler, lightweight, easier to use, much more practical for corporate work, and handles merges more effectively. Also, no rebase & squash. Which is terrible and no one should do it. But everyone does it.
@@thewiirocks not a single company I've worked at has done squashes or prescribed rebases so idk what youre on about. Using git with merges is simple af
@@Tom-jy3in I see it all the time. I had a company I consulted at DEMAND PRs with Squash and Rebase after I repeatedly recommended Trunk based development. We ended up losing some code after the squash and rebase failed to understand that code had been moved around. It simply... deleted it.
@@Tom-jy3in I dread to read your commit history log and trying to find out exactly in which order did a change got into production. We had to force fast forward only rebases before merge to main otherwise the log chronology was absolutely unreadable and filled with garbage "merge commit" entries.
@@Tom-jy3inIn everything I’ve worked on you rebase your own local branch before merging to a shared branch. I agree that I’ve never seen rebasing done in the way prime talks about as a replacement for merge (with the exception of an internship), but it’s more of a courtesy to clean your own commit history before sharing it.
I'm a senior engineer who often helps new people understand how the team uses git. From my experience, the biggest surprise to people is that there are actually three versions of a file (typically), not just the local one and the remote one (the paradigm for Perforce and Subversion). It is the fact that the local "index" contains a checked-out version which is certainly different from local edits but possibly ALSO different from the latest revision on the remote branch that causes the most difficulty.
Don't forget upstream, and potentially many remotes. Also never forget that HEAD can become detached, and point to different version of your file too, which means then you actually have potentially unbounded versions of your file... Which is obviously one of the main points of Git. None of this covers the different copies maintained on disk vs memory. So you can basically double everything there too.
Thank you for the corrections about the additional states. So, yes - there are even more states to be tracked per file than "meets the eye". And the worst thing, according to me, is that many people attempting to explain these things define the new states in terms of their own definition. For instance, a person new to git is surprised about their edited file being different from the local checked-out version. "Oh, you mean the index!" crows the senior dev at them. Blank stare is returned. "If... if you say so," replies the recent hire.
Git is easy, period. Until someone screws everything and then you need to do miracles to solve things like keys pushed, conflicts badly resolved, old code removing new, etc.
@@jkdmyrsif you want an army of Git experts that’s great but understand that comes at the cost of going deep on something else. Specialization was one of the most impactful innovations in human civilization.
@@enginerdy"git expert" is something you can become over a couple week-ends reading the manual pages and trying out a few commands. That's like saying "not every mechanic can be a spanner expert"
@@leeroyjenkins0 Agreed completely. Specially when the needed knowledge to avoid problems is knowing pretty much 4-6 commands, and doing what you're told. Some people don't even read documentation on the git branching strategies and how to work, for god's sake. Or even common sense, how are you gonna hardcode an OpenAI api key into the codebase and push it through git ???
At the time, there was a fundamental difference between Git and Mercurial whenever thinking about large mono-repos. In Git, the storage (in the .git directory) and file system is considered part of the spec. On the other hand, Mercurial has the concept of a virtual file system. A company that would like to use Mercurial could implement their own VFS that knows what files were modified and expose this information to hg. Things changed a lot in the last 10 years.
Never heard of stacking before so I looked it up. There was a lot of text that basically came down to: Keep working on new features by branching off your feature branch while it‘s sitting in PR review instead of main and then rebase to main after the PR is done. They may use different words but that is what you‘d do in git - and we actually do at work. We just never thought of giving it a name…
I can't believe throughout this entire time, nobody mentioned Sapling, which is the SCM currently used by Meta and is as a matter of fact (let's huddle so no one can hear it) written in Rust.
Interview Steve Yegge. His hot take is that Google's internal version control stuff is light years ahead of Git. So it wouldn't necessarily be an upgrade for Google to move to Git as you suggest.
I wonder if their internal VCS is so tuned to their processes, that it would be impossible to make public Or if they simply don't want to get into the space, business-wise
I know Git well, but there are two things that I know people around me find confusing (the latter still confuses me): 1) The difference between the three levels of working and staging area and repo - and when to use "reset" and "checkout" to get the sought version of the file 2) The switch-around of "HEAD" and "incoming" in conflict markers during rebase (fast-forward), and the following "theirs" and "ours" - I know that a rebase (fast-forward) is basically a series of cherry-picks onto the target branch, but it would be much easier if the conflict markers would indicate which branch they belong to, to give better context.
git is difficult just cuz of all of the jargon. I remember at work I was trying to do a git revert. I grabbed the relevant commit SHA, I first tried it on a merge commit, but a merge commit has 2 parents so you have to specify an index, how do you know which parent to target and they are indexed, how do you know which index corresponds woth which parent. after some research I found that I actually didn't need to revert the merge commit and just had to revert a couple of other commits. I also only wanted 1 commit message so I had to add a flag to each revert for that. I was able to accomplish what I wanted but required some time learning. I can see the perspective of not wanting to properly learn a tool like git that functions sort of as a means to an end.
What I’ve found is, and currently dealing with it at my company is, the subset of engineers who find git hard are also the subset of engineers who, if given the chance, would never use source control and don’t care to learn anything about source control. Maybe shit take? But source control to me is the most important tool, if you arnt willing to learn how your source control system works, your a bad engineer.
@@youtubeenjoyer1743 Tell me you know nothing about version control without telling me you nothing about version control. How do you bisect a bug? How do you accept patches from others? How do you revert a change? How do you search the commit log? How do you sign off on commits? How do you guarantee that the source tree hasn't been compromised?
Git has the reputation of being hard for two reasons (I'll let you juge their validity): - You *have to* learn it. You can't just wing it. You can't just google the commands and learn on the way. You have to dedicate some time learning the underlying concepts like: commit, branch, remote, tag, index (or stagging area), working directory and so on. - The commands are names can be confusing. 'rebase' does more than changing the base, it peels off commits (diff+message) and reapply them... possibly on another branch (changing the base), possibly at the same place but making changes along the way. 'reset' might change the working directory, the index, the current branch or all three of them depending on the options. 'checkout' is used to switch branches, but also to retrieve the file of a given commit into the working directory. There are so many more confusing commands, I can't name them all.
The arguments you could oppose are that: - It's a good thing to have people learn. It gives them more power. - There are modern alternative command like 'switch', 'restore' and so on that are much better named. Besides, the old ones make sens if you think about what they actually do on the repo storage.
I think that's part of the problem - we should be using our brain power on writing s/w to solve business problems ( which is our job) rather than have to learn a new flavour of the month tool. Also - I agree - the naming sucks.
@@lotus160 I agree with that. Having a "tool of the month" is a non-sens and counter-productive. (Looking at you, web devs.) Git, however, is much more than that. And it is very much worth every second spent mastering it.
Git: Created by Linus Torvalds, Git's initial release was on April 7, 2005. Mercurial: Created by Matt Mackall, Mercurial's initial release was on April 19, 2005. I first used Mercurial and learned later about Git.
Git's initial release was a very basic version without most commands we use today (even the confusing ones) like "commit". How was the first release of mercurial?
I had a bit of GIT heartburn when I first came to my current employee, as previously I had only used: VSS, CVS, and SVN. After using it for a few months and we had moved away from a mono branch approach, I finally understood wtf it was trying to do.
I started to work with SVN for a brief period of time. Then switched to that Microsoft VC app called TFS and didn't like it. I was reluctant to switch to GIT because of the same reasons people are posting here. Now I don't want to hear about any other VC that is not GIT. It was hard and counter intuitive (why should I stage first?, why do I need to pull, what on Earth is a PR and why do I need it)... but it became all clear. Audited and tracked differential changes.
The few times i tried to explain why i use a git clone instead of the .zip version of the same project it usually goes into they find it easier to use a zip file then to type in command prompt or into terminal. For why i use git? Git pull is quicker then having to redonwload then decompress an entire zip file of the same code.
I started with RCS for years till we migrated to CVS. Then was the migration to svn (with some MS/Rational proprietary stuff mixed in). Then Mercurial for a bit. Git is still “the new kid” - I think I really did not use it much till about 12yrs ago? It seems so odd to hear people say all they have ever used was git. 😂
5:28 - "People dont learn so its confusing to them? Thats a stupid reason!" 5:58 - "It's because you've never actually learned it" *Wtf* he just agreed with the "stupid reason"
Yeah... he contradicts himself a bit here. "I dont understand how people find git confusing..." right after saying that he advertises his git course LOL
@@Braszx fr!! "I don't understand how people find git confusing" comes from a place of too much ego on his part. Even the response when he admits people do find it confusing is "Well you haven't taken the time to learn it" He's portraying a picture that he has never found anything confusing and never struggled with discipline. Bro needs to have some understanding
It's not really a contradiction. He later agreed that it was the reason, and he said it was a stupid reason both before and after. Those two things can be true at once (It is the reason, and it's a stupid one).
Maybe it's not that Git didn't care about supporting large repos, they just didn't see it as a priority then. This happens in SaaS all the time, e.g. ABC Corp wants to use your SaaS product but they need feature X, but you're not ready to develop and support feature X yet.
Mercurial was made at the same time as git with the same goal. For use with the Linux kernel after they stopped using BitKeeper and they needed a replacement that fit what Torvalds was looking for. Obviously git won that contest and took off after that. So it shouldn't be a surprise that Mercurial is more obscure.
"Never taken the two hours of time it takes to learn git well enough to not be confused by any of it" This is in fact, the concise explanation you were looking for. We're so adapted to how git works at this point we just accept that taking two hours to learn it is reasonable, rather than iterating on it's core to improve it's usability with an aim to get that onboarding time down to a minimum. Instead we've decided pass that responsibility to a handful of third party websites that have grown to dominate the industry.
What really blows my mind is that most people don't take this same time to learn other VCS like hg, fossil or pijul and compare their experiences. Everyone just assumes git must be the best for everything, because everyone is using it.
This. Git's documentation is horrible, and the onboarding experience is horrible. "It's easy if you buy my class" is a horrible answer that we would rightfully call a scam in any other industry. Even when I know what Git flag I'm looking for, it's always faster to just search for the answer on Stack Overflow, than it is to try and find the answer in Git's docs. And I know what I'm looking for. If that's not a sign of a serious usability problem, I don't know what is. How are newbies even supposed to know what questions to ask if they don't know anything about the tool?
That hot take on GIT being easy and just needs a little learning time was spot on. Same thing here though where I get strange sync issues once in a while where rebasing is the solution. GIT is the best
Honestly the Git vs Hg thing is more nuanced than just "Git had Github" since Hg had Bitbucket which at the time was feature comparable (and Hg exclusive). Git had the kernel, but Hg had plenty of big names using it too like Mozilla. Early on (back when svn was as popular as git today) Hg had better user experience with a decent cross platform GUI tool, a more familiar CLI (for those switching from svn), and Bitbucket even let you have private repos for free which Github did not at the time. I believe part of the "git is hard" sentiment is parroting from those days since if my memory serves even git's supporters admitted that the CLI experience was a bit raw (i.e. cryptic messages). Over the years Hg's advantages would be chipped away, especially after Bitbucket added Git support and clearly favored it. As someone who supported Hg up until Atlassian dropped support I am kind of surprised Git managed to steamroll everything based on where it was. Obviously today things are very different, but I don't think we got here by any singular facet.
As far as I remember git was used because people wanted to use github, while bitbucket was more of a 'github of hg' thing. So bitbucket was only used by hg users that looked for a similar experience. The reason is probably, that early on popular OSS project were on github. Something I didn't understood (and still don't), as we just came from the aftermath of the Sourceforge disaster and I didn't want to rely on a third party again.
At least my experience has been that when using rebase you're going to be solving merge conflicts just like you would with a regular merge. Maybe you can find some more unusual cases where it gets more difficult but I've not come across those.
@@4Bakers the first time is the hardest time, it'll eventually make sense and be awesome I promise! It will help to read the documentation too though, and watch videos/ask questions to more experienced devs too! :)
This is it imho. The concepts are simple once you grasp them, but when you’ve never seen git a fjcking “git commit”, “git checkout” or “git rebase” means nothing to you intuitively.
@@_alexlazar_I feel the same. Especially as a not native speaker a lot of the words refer to concepts that I would've no idea were being used for maintaining the repo.
Git seems hard because everyone wants to learn the process instead of the architecture. They want to remember the steps, because wrapping your head around the idea of a differential audit trail or the fact that your workdir is just a bunch of diff files merged together is not immediately intuitive
@@MustNotContainSpaces it is. HEAD is a reference to a commit, which is just a bunch of diffs bundled together with a parent. You follow the chain until it ends, and apply the diffs in reverse
@@shaunkeys7887 a git commit references it’s parent(s), but that's only metadata and is not used to process the content of your workdir. If it were otherwise, you couldn’t do something like a sparse checkout.
This. Git has become far far less confusing to me since I started to try and understand what actually happens when you perform the commands. Remembering the set of steps to achieve X, then another set of steps to do Y is a poor way of learning such tools. When you understand how Git works it's impossible to fuck up your branch, and even if you do you'll always know how to fix it
Well, that's the point of a tool right? I want to use my hammer to hit a nail. I don't want to take a metallurgy class to learn about how the hammer's metal is composed nor a physics class to learn about all of the forces applied. I want my tool to do it's job in the way I expect it to which git is inarguably terrible at
This was interesting. I used to work for a company where the repo was in SVN, but it was very slow. Then - after a long consideration - it was migrated to HG, but they're now using GIT. BTW CVS != CSV. Also, why use a monorepo at all?
Amazingly many people made false assumptions about the costs of stat of a million files - on local ssd this is very quick. When you try using a network drive or spinning disk or a compressed file system, things all slow down dramatically. Also caching with enough memory means local repos stat results get cached so RAM helps a lot. But fundamentally codebases need modularisation and project separation so they don’t grow too monolithic
Wow. Git was a breath of fresh air compared to all prior source code management systems. Migrating off mercurial saved a lot of problems but mercurial itself was also an improvement on prior systems.
I don't understand why people made up this term "stacked diffs". Everything in git is a "stacked diff" in some sense, and branching off non-main branches is a core aspect of git. I feel like people really conflate git with github, where it's the PR that creates this proclviity towards "unstacked" diffs.
I found myself having to teach coworkers git a lot, and I always begin with the directed acyclic graph thing. It's what made git click for me. When I perform git actions I actually visualize the nodes moving around.
Used git my whole career, then I moved to a massive tech company with thousands of employees and found out they used mercurial. Now they are moving (or trying to) to git and I am upset :( I like mercurial so much better then Git. It just feels easy, git feels nasty and complicated. When I go back to using Git I don't feel like I've escaped the horror, more like I'm returning to it :(
The post got bashed on reddit. Basically: - the issue was niche. While git people didn't just blindly did what they were asked and instead propose better way to manage the project, fb would just not listen. On the opposite side, Mercurial people did the "promise the world" thing to get the customet. - it is not all of facebook, just some teams - git is easy, it is not that "you get stuck", but people think it is strange that issue arise when you don't know how a tool work.
guys how can I get informed about what Prime is up to? like he mentioned he is going to be working on HTTP on September but how can I get notified about this?
But practically it's almost exclusively used in cases of quoting text with an error in it to note that the error was in the original and not added later. In this case, the grammar seems to be slightly off.
About git and rebasing. I found that people that do not care about other people PRs and what is going in their own project are having trouble with resolving conflicts. Becasue sometimes you need it takes a bit more than just simple merging to files to resolve the conflict. And to do that, you need to know what was the intention of the change of that other person and what is your intention for change in the code.
i've used git since like 2011 and it wasn't til sometime earlier this year that I learned that there are 3 pieces to the puzzle: your local branch, the local repo that tracks remote, and remote repo. For a long time i'd be confused with the message 'my local branch is up to date with origin/', but that can't be true cause I knew someone just merged into remote. that message is really telling you that your local branch is up to date with the local repo, which tracks the remote repo. I got away with this for almost 15 yrs lol
yea, i think the most confusing thing about git is it's English. Especially for non native speakers like me, a lot of words are similar and interchangeable but they have completely different meanings with respect to git. If they made up their own words or used verbose commands it would be great.
@@phoneywheeze in my case i would fully attribute it from just learning on the spot and not really learning those concepts at a base level - like even though I was confused by it, it always worked, so I never really felt like I needed to make sense of it. Not until recently, when I decided that I should have a better overall understanding of my dev tools
facebook "created" stacking patches as much as git "created" diffs, lol, they just popularized a long-known good idea... Darcs is way better for this kinda stuff, it was made in 2003, and it's still active (last release in may of 2024, as of now), and the entire point is "focus on changes rather than snapshots", where you work with changesets, not snapshot histories, you work with patches, not diffs, you can easily swap your patchsets around, or create another patch to fix a conflict, it's ideal for having a parallel workflow
Two things I don't like about rebase: With conflicts and multiple commits on the changed file, you have to solve the conflict over and over again. You rewrite history which is why you have to force push on your feature branch. If someone else also worked on the same branch and does a pull nothing fits anymore and git proposes to merge. It the other dev then merges the changed and rebased history into his own local version it becomes fucked up.
honestly stacked diffs seem pretty cool. i am big supporter of using text based solutions instead of binary blobs. can always use a filesystem that is text file optimized and has anti redundancy features like git has.
Just a few: Pull/Fetch/Checkout/Clone all different things (Pull/Fetch should be same thing w option flag) "Checkout" means "switch branch" A "branch" is just a pointer to a commit "Pull request" is a push request A branch doesn't always point to the latest commit, and neither does HEAD!
No, just no. "Checkout" checks out any reference. That it works on branches is just natural, but if it is confusing you just switch branches with "git switch". A branch is a pointer to a commit, true. But each commit hold info on it's parents, so there you have your "real" branch. And a PullRequest in OpenSource is actually really a pull request, because somebody with write access needs to "Pull your changes". If you work in a company with the "protected trunk/main/develop branch" method, then you could also just call it "merge" request, that's fine. And the last sentence just underlines, that you too didn't take the afforementioned 2 hours to learn what git is... complaining that HEAD does not point to the "latest commit" (whatever that is) is just mindblowing to me :D PS: Forgot your first point as it's crazy :D not going into pull vs fetch ... That I leave to the web based trainings you should've taken at your work :D
100% agree. I'm a Mercurial user as well. It's a lot easier to use and saner, with almost no way of shooting oneself in the foot. Git was designed for specific needs for maintaining the Linux kernel. It's much too convoluted and easy to screw up a repo.
@@joseoncrack Exactly, hence why I don't get Primes "you use rebase wrong" - if there's any other way than proper one to handle rebase, your tool is not UX friendly with regards to rebase.
@@d3stinYwOw I really wonder what made git so popular in the first place. How did that start? I mean, the Linux kernel is kind of a niche in the whole software industry. That project alone wouldn't have triggered such a frenzy around git. I'm always curious about what triggers popularity of tech tools.
I am a git master in intellij. I only use the cli to unblock my branch when intellij bricks my brach. Now I am no near a master on the git cli I can do basic things but I for sure can not resolve merge conflicts in the cli.
when I transited from SVN to GIT, git was very confusing to me, I could not graps the difference between git add, git commit, git push, local and remote version of the branch.
@@albanx1 Sadly the git manual does a poor job of explaining there are FIVE different places a git command can interact with: * stash (local) * workspace (local) * index (local) * local repository * remote repository
Git is maybe easier when coming from SVN because it makes you appreciate all the tooling Git provides that SVN didn't. Like doing a rebase in SVN is usually organization-specific and there is no proper way to do it. You could merge trunk into your branch, or recreate your branch from trunk and merge your feature, or attempt to recreate a Git rebase by merging commits one by one. Some people write scripts to do all this, otherwise what should be a simple rebase takes a ton of time in SVN. So then you start using Git and the rebase feature is a godsend, never mind not being forced to do remote-centric version control. Can't even imagine rebase being confusing unless you're doing something insanely complicated on a regular basis.
People beware of stacked PRs with squash merges, it will mess your codebase, you have to squash merge PR 1, then interactive rebase PR 2 to drop the commits that were squashed (of course you'll have to force push), after that you can merge any way you like, including squash merge PR 2 (unless you have a 3rd stacked PR, in such case you start over).
git felt hard when I was learning it, but once I learned what all the commands where it immediately stopped being confusing. Git is not hard, its just a lot of commands to memorize for the new git user
I think you've isolated the core issue; I've thought that a lot of confusion from git comes from people describing the system by using inaccurate language and ambiguous prepositions, which don't really make sense. For example, people often say things like "merge the feature onto master", which doesn't fit the meaning of "merge", as it would be correctly be "merge the feature _with_ master". And then there are boutique verbs like "rebase" or "diff" (a noun actually?) that don't really fit into English sentences. There are tons of other examples, and often the people explaining procedures don't really understand the tool themselves, so they are forced to describe the process vaguely.
I think why a lot of new-ish developers aren't getting git 100%, is that a single dev, freelance or hobby oftentimes aren't cooperating with other people on larger projects, and typically only need to add, commit and push. A single dev working on something don't have to make a separate branch for a feature, they can work all they want on main where no merging is needed, and simply push it when it's done and testet locally. They simply aren't used to other people messing around in the code base, leading to conflicts *insert possum don't touch my garbage meme*
I'm with you that git is overall pretty good. However, there are definitely areas where it's not truly user friendly. In general, command line tools aren't too user friendly, since the --help command usually doesn't tell you "these are the most common things you are going to want to do and the syntax for those, but if you need something more advance, there are these commands and options, too:" and instead you need to spend a lot of mental processing cycles on figuring that out what are the 2-3 commands you are actually going to be using most and how to use them. Then there are common flows like rebasing where they actually require knowledge of --force flags, which come with drawbacks. If that is supposed to be a common flow, the drawbacks should have been mitigated earlier, but the --force-with-lease flag didn't exist until much later and the -f flag doesn't use that. There's also an even newer option called --force-if-includes, and from a first-time user perspective, this is a really confusing API. Naming-wise, the existence of branch and checkout commands (which the latter actually creates a branch, too) is not the best. That's why the switch command was added in newer versions of git, but you still have all of the old commands available, older tutorials are still going to tell you about older methods, and as a new user you're going to have to figure out how to filter through a lot of old information to really figure out how to use the tool. That's not to mention that merge conflicts are still, IMO, most easily handled via UI and IDEs. Resolving them in the cases where there was an overlap in development at all tends to not be easy and I find myself frequently having to edit by hand and then compile and retest the code. Even sometimes in cases where the changed lines were side-by-side and not truly changing the same code. It could for sure be a lot worse, but I feel like you basically can't easily learn to use git from git itself and have to rely on a lot of external tutorials and tooling to actually use it in a reasonable fashion.
Stream chat reeks of Dunning Kruger and skill issue, but then again which twitch chat doesn't? Literally most of those arguments are "git sucks because it sucks", one person made a good comment about scalability at monstrously large codebases which isn't an issue for 99% of people and companies.
4 หลายเดือนก่อน +21
Thank you Prime for voicing the "Git is easy. Just spend the minimal effort to learn its basics and you won't be confused"
I'm known as the git expert at my company. I think most of my peers just learn the basic commands and google their way out. Which is how we do most of coding. However, all I did was watch a few videos on Git and practiced and instead of relying on commands they told me to run, I applied the knowledge I knew to do what I felt made sense. I don't want to say it's easy but I certainly think every programmer can solve most issues if they put that extra effort in.
I'm the resident "git expert" at my work. Everyone uses Source Tree to do their work. Meanwhile I do my git stuff off the command line. Whenever they have an issue, I make them pop open the terminal, and teach them the commands. Some of them still refuse to just adopt CLI. Many of the reasons I'm good with Git and fix almost any problem is because I use the CLI. Don't know a command? 'git [command] --help' is all you need to put in to get the docs. Afterwords it is a matter of just picking a diff tool and binding it. You can do a few more other customizations like shortcuts but I barely use them. Tab completion is good enough and my processes are just commit and add files with occasional pull for updates.
@@ChrisCarlos64 The CLI feels better for many things but trying to do things like line staging in the CLI is comparatively kinda painful. Also exploring the history is much better with an actual graphical visualization of the commit graph.
Mercurial was great and I preferred it over git when they both started gaining popularity, I'm a little sad git won, but github is a better name than hghug
Git is one of those things that makes a lot of sense once you understand it, but it's a lot to learn before you understand it and feel confident. My team has been with me for FOUR YEARS and they still don't quite understand how feature branches work. It's actually so simple, but somehow it still confuses them. And I understand because coming from TFS it was a lot of extra stuff to learn.
Git is not hard, but it goes in the way of devs instead of just working. People don’t want to spend hours learning version control, they want to actually code.
@@paul_w I agree on this one. With a power tool e. g. I know what its used for. And I really do need a drill. With git its always kinda the same "everybody uses it, so you must too"
Weird take. Most things in our industry is hard and you need to learn them because they are essential to programming. The build system, the version control, ci pipelines, test frameworks, containers, config files etc. There are a million things that we need to know you will never get to the place where you can just write some logic and be done for the day. We write in c++ and I always tell people the easiest part of our job is writing in c++. It is everything surrounding it that is difficult because it is there you can have actual errors and slowdown in productivity.
This channel doesn't miss a chance to spread FUD about Python. Object oriented programming in Python is wonderful. And if you disagree, you can go back to pulling your hair out trying to write a GUI in Rust.
I had to stop and think for a moment how the hell one guy wrote a version control system from scratch with no tutorial on how in 5 days. That is seriously incredible. I didn't know it was that quick.
Just don't mono repo. It stops scaling eventually - doesn't matter if its Git, Mercurial or something else.. It's like vertical scaling hardware. You can do that for a while but it will stop to work eventually.
Back when we used svn we had a monorepo for all stuff in the company (small company though). As svn allows you to checkout subtrees it was no problem, each project had it's own tree. But it made it incredibly easy to use parts of code from another project, as it was the same repo you could svn copy it. Monorepos have their advantages. We never had performance and scaling issues as well, but yes, we aren't exactly Google.
@@Mnementh-ub8mdthe only ones having issues with monorepos is git-heads. so their solution is to announce monorepos an anti-pattern, unscalable and other fud.
I'm shocked that Prime is so surprised at the idea of 14 million files being realistic. I work at Meta, we have *easily* more than 14 million files in the mobile repo alone.
Can someone explain why you'd have millions of files in a repo? What possible benefit could that have over splitting this Galactus-sized mono-repo up into smaller repos? Also why do you need to care to version track millions of files? I'm having a hard time imagining that this would be necessary but I'm curious and open to any answers. I do come from the embedded software world, so maybe this is a web dev thing. 🤷♀ For me, most files are only generated for a build and then no longer necessary afterwards, so the core repo is far fewer in size.
@@aqua_pi Thanks for replying! I see some of what you mean, but... Hmm... Well, in my company, a group of developers are given access to all repositories in a give GitHub organization. So you can still have access to repositories split up. And following similar practices comes from 1) clearly documenting coding standards and expectations somewhere, 2) ensuring code standards are maintained already, regardless of where you look; 3) having project seniors enforce those on PRs and other code reviews; and 4) good organizational training/education.
@TenFrenchMathematiciansInACoatwhat? no. fb main repo has everything from data infra services to network switch custom firmware. the size primogen found laughably unrealistic turned out to be underestimated fairly soon. it’s not hard to get to this size once you do your own custom everything from compilers to kernel, and there are serious benefits when working collaboratively and the core / products have certain dependencies.
Git is only hard for people who can't resolve merge conflicts. Here's a fun story involving merge conflicts that happened at my previous job: I was hired as a senior frontend dev (React) and we were staring some new projects I have created the frontend repo for the first project and setup the structure of the project, a readme file for instructions (since other devs were juniors and they never used react) and some basic CI/CD pipelines. The team leader comes from her vacation and the first thing she does is to ask the devops to downgrade my access to "developer" because "she is capable of maintaining the repos herself and will handle merge conflicts" (she's not my superior btw, just some weird corporate hierarchy). Comes first merge conflict, she couldn't do anything for 3 days and then asks the devops to make me a maintainer so that I could resolve the conflict :v
not only large-scale repos (in terms of the number of files) can be a problem, but also repos stored on remotely mounted file systems. the slowness is proportional to both the I/O latency and the number of I/O calls.
@@kyjo72682 it is, in a way. if there is a significant number of I/O calls (such as stat) that the program has to make to complete an operation, then it will feel slow if the file system has high latency. the lower the number of i/o calls, the better.
4 หลายเดือนก่อน
As a git user the biggest thing that makes it hard for me is the absence of Magit for Mercurial. The other smaller issue is that git felt at least from my pov simpler but more complex when going further.
@TenFrenchMathematiciansInACoat gargle writes some of the worst C++ out there yet one of their core public-facing C++ products (chromium) is one of the most successful pieces of software in existence. This despite being objectively terrible in both code quality and functionality.
@TenFrenchMathematiciansInACoat I understand the argument, it's also true of Microsoft and their MS-DOS and later Windows operating systems. The industry doesn't like them. Still they owned everyone at some points and made quite some money. On technical grounds it's another story, like usual.
@TenFrenchMathematiciansInACoat Yes, I'm not a fan of PHP. Beside, I've never used their website, not once in my life. I've heard it was "has-been" after ten years of existence or something. The only good point of Facebook is probably they have a guy who contributes to GCC. I do use GCC, so there is that.
I've seen videos about how deleting private git code doesn't delete it from the public, in some cases. Something to do with the assumption people make of what 'private' means.
I have done the full cycle. I have used RCS, CVS, Subversion, and git. I briefly worked on a project that used hg but was only pulling code from that repo. I still use RCS at times and prefer Subversion for personal projects. git is ok until you have to deal with a merge conflict or find you have multiple stashed changes. At that point you need a deeper dive in to how to use git. Git is the only VCS that has resulted in me losing unsaved changes that I had to redo from scratch. While learning git I had to create my own cheat sheet on how to use it. Currently it is over a full page long. I only use git because Open Source projects I contribute to use it. If not for that I would stay away from it.
The git client is hard, not git. There's a reason that there are a million paid tools to interface with git. If you look at git docs there are several ways to do things and they all have several possible parameters, and their explanations tend to be very technical, creating situations where you open the docs with one question and leave with many more. I absolutely hate when I have to use git directly, even though I love that when I have to it does have everything I need to fix whatever problem I'm having. TLDR: I think git docs need a "basic" version, with the most common commands already with the most common parameters, followed by explanations that are way less technical than what it has right now, and an advanced version that throws the book at you - what it has right now. That's what paid git tools are offering, shortcuts to routine operations.
Simple question: are you too stupid to use git? It’s so simple and well defined that if the answer is yes, you’re probably incapable of doing your job either. Skill issue. A huge one. Like all those “I only use gui” pussy “programmers”
Google last time I checked is still using an enormous monorepo. Which they insist is more efficient, but I frankly think it's cope. I'm sure with the tooling it's about equal, but I think they could've easily converted to git and been fine had they done it early enough.
git isn't hard. but solving issues can be absolute hell. +1 pain if the person you're working with does not understand git, which is 60% of the time. +1 pain if there is a person going crazy with its advanced functions where i find my local behind remote in so many things.
I have lots of coworkers struggling with git and I thought about why, ans my conclusion was, that they started off with a GUI tool which does multiple git commands in background per click, and they never really tried to learn git commands. An then those people tell freshers stuff like "never use rebase, it is weired and destroys everything" who will then also struggle. I started off the same way and I'd say, I'm not a shell only guy, but when it comes to git, I really enjoy using CLI instead of any GUI.
Perforce here, and I've always much preferred its P4V GUI utility - would really like to see that re-adopted/factored for Git honestly. Aside from its Flow & Layout, its default Hotkeys just felt better/more natural e.g. select changed file and Ctrl+D for its Diff presented graphically, and even editable in it too.
I'm not familiar with P4V GUI, but there are tons of different GUI interfaces for Git besides the official one, maybe you'd be interested in giving them a try
I was using mercurial and bazaar before moving to git and it was really a bliss to start get responses from any version control commands in few hundred milliseconds (using git) instead of few seconds on python based version controls. Maybe those people who cared about it in facebook just kept using git for their work and used adapter to push their code finally to mercurial when it was really necessary to push to remote 🤷♂
Hg is the same as git just with better branch management. And Prime, do you actually think a million file repo is rare? Companies that use perforce or clearcase are usually giant monorepos.
That file checkout and it comes back issue happens when you have a file named something like AAA.json and aaa.json committed into the repo from a computer with a case sensitive filesystem and then you try and handle those files in git on a case insensitive filesystem like on a Mac.
Microsoft switched windows source over to git and solved the massive file sizes and added support for partial downloads so that not every developer needed multiple GB of source. So yes GIT today can handle very very big code bases.
Never heard about this react framework called git
All i know is react. LMAO
Tired of that command line nonsense? Just do version control in JavaScript😂
Bruh 🤣
Git gud!
GIT is hard for people who hold branches for months and then they're surprised that the merge conflicts will take weeks to untangle.
trunk based is now proven as a best practice
I push everyday before I leave it only makes sense
@@nehemiah6280 So what if you are pushing daily? Are you pushing into the main branch? The issue the OP talks about is you being slow and falling behind the trunk and unless you are pushing daily to trunk (which is retarded) there's no way your daily pushes make anything better. If anything it tells me you are one-man-show.
I push every friday at the end of the day to production
@@eleandres Even if you dont want to do that, its easy enough to rebase often as well. There are so many solutions.
I started working at Meta (called Facebook then) in 2014. We used Git then. The sauce at the time was that we switched to Mercurial because although neither Git nor Mercurial could scale to our needs, there was a lot more friction upstreaming our scale patches to Git than to Mercurial. And we didn't want to maintain our own fork.
FWIW, let's just say that those estimates on repo size turned it to be *under* estimates.
The stacking stuff is unrelated to git vs hg, though. We used stacking for both. We actually have a wrapper around the source control stuff anyway, so many/most people didn't even notice when it switched.
thanks for the input, I love hearing insights from the inside too
I heard Google has their own source control would love to their reasons why as well
To be fair, with how source control software works i can't really think of anyway to make it scale well other than just merging really frequently
Errr putting ketchup on git aint gonna work.
Sauce?? If you worked as a coder on any level and still dont know the diff between Source and Sause i can see why you dont still work there
Git is probably confusing due to a lack of context around the problems its trying to solve. The entry level user is just trying to check out and save progress. The only tools they need is to be able to create backups and download files. Then they're introduced to a complicated tree system and CLI designed to solve a series of problems relating to group development over time and space with steps like staging and branching.
GIT is designed for OSS (specifically Linux kernel) work. It's fantastic at that, providing complex branch management, SSH key signoffs, and a ton of other stuff that allows it to float out in the public space. It's a shitty tool for corporate work.
Mercurial is way simpler, lightweight, easier to use, much more practical for corporate work, and handles merges more effectively. Also, no rebase & squash. Which is terrible and no one should do it. But everyone does it.
@@thewiirocks not a single company I've worked at has done squashes or prescribed rebases so idk what youre on about. Using git with merges is simple af
@@Tom-jy3in I see it all the time. I had a company I consulted at DEMAND PRs with Squash and Rebase after I repeatedly recommended Trunk based development. We ended up losing some code after the squash and rebase failed to understand that code had been moved around. It simply... deleted it.
@@Tom-jy3in I dread to read your commit history log and trying to find out exactly in which order did a change got into production. We had to force fast forward only rebases before merge to main otherwise the log chronology was absolutely unreadable and filled with garbage "merge commit" entries.
@@Tom-jy3inIn everything I’ve worked on you rebase your own local branch before merging to a shared branch.
I agree that I’ve never seen rebasing done in the way prime talks about as a replacement for merge (with the exception of an internship), but it’s more of a courtesy to clean your own commit history before sharing it.
I'm a senior engineer who often helps new people understand how the team uses git. From my experience, the biggest surprise to people is that there are actually three versions of a file (typically), not just the local one and the remote one (the paradigm for Perforce and Subversion).
It is the fact that the local "index" contains a checked-out version which is certainly different from local edits but possibly ALSO different from the latest revision on the remote branch that causes the most difficulty.
There are 4 versions: remote branch, local branch, workspace and staged
@@halbesbyte"there are four lights!" - Captain Picard
Don't forget upstream, and potentially many remotes.
Also never forget that HEAD can become detached, and point to different version of your file too, which means then you actually have potentially unbounded versions of your file... Which is obviously one of the main points of Git.
None of this covers the different copies maintained on disk vs memory. So you can basically double everything there too.
Thank you for the corrections about the additional states. So, yes - there are even more states to be tracked per file than "meets the eye". And the worst thing, according to me, is that many people attempting to explain these things define the new states in terms of their own definition.
For instance, a person new to git is surprised about their edited file being different from the local checked-out version. "Oh, you mean the index!" crows the senior dev at them. Blank stare is returned. "If... if you say so," replies the recent hire.
öhio man said the following as a reply: no way this is annoying af why sare there so many diffrences between them
Git is easy, until it's SUDDENLY confusing. I've called in the cavalry to resolve a weird merge more times than I can count.
Git is easy, period. Until someone screws everything and then you need to do miracles to solve things like keys pushed, conflicts badly resolved, old code removing new, etc.
So you call in the people that took the time to learn what they’re doing.
Or, you could learn the tool that’s necessary for your job.
@@jkdmyrsif you want an army of Git experts that’s great but understand that comes at the cost of going deep on something else. Specialization was one of the most impactful innovations in human civilization.
@@enginerdy"git expert" is something you can become over a couple week-ends reading the manual pages and trying out a few commands. That's like saying "not every mechanic can be a spanner expert"
@@leeroyjenkins0 Agreed completely. Specially when the needed knowledge to avoid problems is knowing pretty much 4-6 commands, and doing what you're told. Some people don't even read documentation on the git branching strategies and how to work, for god's sake. Or even common sense, how are you gonna hardcode an OpenAI api key into the codebase and push it through git ???
At the time, there was a fundamental difference between Git and Mercurial whenever thinking about large mono-repos. In Git, the storage (in the .git directory) and file system is considered part of the spec. On the other hand, Mercurial has the concept of a virtual file system. A company that would like to use Mercurial could implement their own VFS that knows what files were modified and expose this information to hg.
Things changed a lot in the last 10 years.
Git is brilliant in that they can take common version control terms and make them do something else.
Sounds like Unreal Engine
"Reverse engineered the bitkeeper protocol"
He telneted to the bitkeeper port and typed "HELP".
It was more than that
@@thewhitefalcon8539 Read his writeup. It wasn't. Implementing it was more work, but reverse engineering the protocol was just telnet and help.
Never heard of stacking before so I looked it up. There was a lot of text that basically came down to: Keep working on new features by branching off your feature branch while it‘s sitting in PR review instead of main and then rebase to main after the PR is done.
They may use different words but that is what you‘d do in git - and we actually do at work. We just never thought of giving it a name…
The tooling is what makes it viable.
I thought I had watched the exact same video before but then remembered it was Theo’s video about the same article!
same
Whoow😅
Says something about react content doesn’t it?
Exactly the same for me lol
Its reupload?
I can't believe throughout this entire time, nobody mentioned Sapling, which is the SCM currently used by Meta and is as a matter of fact (let's huddle so no one can hear it) written in Rust.
Interview Steve Yegge. His hot take is that Google's internal version control stuff is light years ahead of Git. So it wouldn't necessarily be an upgrade for Google to move to Git as you suggest.
That would be fun. Used to love reading his blog posts back in the day.
@@PassifloraCerulea Best rants in the business!
I wonder if their internal VCS is so tuned to their processes, that it would be impossible to make public
Or if they simply don't want to get into the space, business-wise
Came here for the tech history, stayed for chat being flabbergasted by git
I know Git well, but there are two things that I know people around me find confusing (the latter still confuses me):
1) The difference between the three levels of working and staging area and repo - and when to use "reset" and "checkout" to get the sought version of the file
2) The switch-around of "HEAD" and "incoming" in conflict markers during rebase (fast-forward), and the following "theirs" and "ours" - I know that a rebase (fast-forward) is basically a series of cherry-picks onto the target branch, but it would be much easier if the conflict markers would indicate which branch they belong to, to give better context.
git is difficult just cuz of all of the jargon. I remember at work I was trying to do a git revert. I grabbed the relevant commit SHA, I first tried it on a merge commit, but a merge commit has 2 parents so you have to specify an index, how do you know which parent to target and they are indexed, how do you know which index corresponds woth which parent.
after some research I found that I actually didn't need to revert the merge commit and just had to revert a couple of other commits. I also only wanted 1 commit message so I had to add a flag to each revert for that. I was able to accomplish what I wanted but required some time learning.
I can see the perspective of not wanting to properly learn a tool like git that functions sort of as a means to an end.
What I’ve found is, and currently dealing with it at my company is, the subset of engineers who find git hard are also the subset of engineers who, if given the chance, would never use source control and don’t care to learn anything about source control. Maybe shit take? But source control to me is the most important tool, if you arnt willing to learn how your source control system works, your a bad engineer.
Based.
I have a script that zips up the current directory and uploads it to my server under a unique name. Do you really need more?
@@youtubeenjoyer1743It's gonna fill up real fast. And team work?
@@youtubeenjoyer1743 Tell me you know nothing about version control without telling me you nothing about version control.
How do you bisect a bug?
How do you accept patches from others?
How do you revert a change?
How do you search the commit log?
How do you sign off on commits?
How do you guarantee that the source tree hasn't been compromised?
@@MichaelPohoreski Sorry, I’m not a web developer.
Git has the reputation of being hard for two reasons (I'll let you juge their validity):
- You *have to* learn it. You can't just wing it. You can't just google the commands and learn on the way. You have to dedicate some time learning the underlying concepts like: commit, branch, remote, tag, index (or stagging area), working directory and so on.
- The commands are names can be confusing. 'rebase' does more than changing the base, it peels off commits (diff+message) and reapply them... possibly on another branch (changing the base), possibly at the same place but making changes along the way. 'reset' might change the working directory, the index, the current branch or all three of them depending on the options. 'checkout' is used to switch branches, but also to retrieve the file of a given commit into the working directory. There are so many more confusing commands, I can't name them all.
The arguments you could oppose are that:
- It's a good thing to have people learn. It gives them more power.
- There are modern alternative command like 'switch', 'restore' and so on that are much better named. Besides, the old ones make sens if you think about what they actually do on the repo storage.
I think that's part of the problem - we should be using our brain power on writing s/w to solve business problems ( which is our job) rather than have to learn a new flavour of the month tool.
Also - I agree - the naming sucks.
@@lotus160 I agree with that. Having a "tool of the month" is a non-sens and counter-productive. (Looking at you, web devs.)
Git, however, is much more than that. And it is very much worth every second spent mastering it.
Git: Created by Linus Torvalds, Git's initial release was on April 7, 2005.
Mercurial: Created by Matt Mackall, Mercurial's initial release was on April 19, 2005.
I first used Mercurial and learned later about Git.
Me too, disgruntledly had to learn git because "everyone" uses it now.
What's the point of this
Now Olivia Mackall.
@@M43782 Yikes
Git's initial release was a very basic version without most commands we use today (even the confusing ones) like "commit". How was the first release of mercurial?
I would be super interested in knowing more about this "stacking" approach vs "diffs" mentionned at the end of the video.
I had a bit of GIT heartburn when I first came to my current employee, as previously I had only used: VSS, CVS, and SVN. After using it for a few months and we had moved away from a mono branch approach, I finally understood wtf it was trying to do.
I started to work with SVN for a brief period of time. Then switched to that Microsoft VC app called TFS and didn't like it. I was reluctant to switch to GIT because of the same reasons people are posting here. Now I don't want to hear about any other VC that is not GIT. It was hard and counter intuitive (why should I stage first?, why do I need to pull, what on Earth is a PR and why do I need it)... but it became all clear. Audited and tracked differential changes.
The few times i tried to explain why i use a git clone instead of the .zip version of the same project it usually goes into they find it easier to use a zip file then to type in command prompt or into terminal. For why i use git? Git pull is quicker then having to redonwload then decompress an entire zip file of the same code.
I started with RCS for years till we migrated to CVS. Then was the migration to svn (with some MS/Rational proprietary stuff mixed in). Then Mercurial for a bit. Git is still “the new kid” - I think I really did not use it much till about 12yrs ago? It seems so odd to hear people say all they have ever used was git. 😂
5:28 - "People dont learn so its confusing to them? Thats a stupid reason!"
5:58 - "It's because you've never actually learned it"
*Wtf* he just agreed with the "stupid reason"
Yeah... he contradicts himself a bit here.
"I dont understand how people find git confusing..."
right after saying that he advertises his git course LOL
@@Braszx fr!!
"I don't understand how people find git confusing" comes from a place of too much ego on his part.
Even the response when he admits people do find it confusing is "Well you haven't taken the time to learn it"
He's portraying a picture that he has never found anything confusing and never struggled with discipline. Bro needs to have some understanding
It's not really a contradiction. He later agreed that it was the reason, and he said it was a stupid reason both before and after. Those two things can be true at once (It is the reason, and it's a stupid one).
LOL, "I went hard on Tor-twazzz!" Your pronunciation humor is great! I also love Chat Jippity! Keep it up!
Maybe it's not that Git didn't care about supporting large repos, they just didn't see it as a priority then. This happens in SaaS all the time, e.g. ABC Corp wants to use your SaaS product but they need feature X, but you're not ready to develop and support feature X yet.
Mercurial was made at the same time as git with the same goal. For use with the Linux kernel after they stopped using BitKeeper and they needed a replacement that fit what Torvalds was looking for. Obviously git won that contest and took off after that. So it shouldn't be a surprise that Mercurial is more obscure.
I do hate AirBNB linting rules for JS, because teams adopt it as it was the bible where it is just a pain in the a**
"Never taken the two hours of time it takes to learn git well enough to not be confused by any of it"
This is in fact, the concise explanation you were looking for.
We're so adapted to how git works at this point we just accept that taking two hours to learn it is reasonable, rather than iterating on it's core to improve it's usability with an aim to get that onboarding time down to a minimum.
Instead we've decided pass that responsibility to a handful of third party websites that have grown to dominate the industry.
What really blows my mind is that most people don't take this same time to learn other VCS like hg, fossil or pijul and compare their experiences. Everyone just assumes git must be the best for everything, because everyone is using it.
This. Git's documentation is horrible, and the onboarding experience is horrible. "It's easy if you buy my class" is a horrible answer that we would rightfully call a scam in any other industry. Even when I know what Git flag I'm looking for, it's always faster to just search for the answer on Stack Overflow, than it is to try and find the answer in Git's docs. And I know what I'm looking for. If that's not a sign of a serious usability problem, I don't know what is. How are newbies even supposed to know what questions to ask if they don't know anything about the tool?
Tech corporations making cringy nouns for their employees is so awful.
That hot take on GIT being easy and just needs a little learning time was spot on. Same thing here though where I get strange sync issues once in a while where rebasing is the solution. GIT is the best
Emails are a good medium and no I will not back down from this opinion.
Somebody should do something about the major providers blocking small fish and self-hosters
Honestly the Git vs Hg thing is more nuanced than just "Git had Github" since Hg had Bitbucket which at the time was feature comparable (and Hg exclusive). Git had the kernel, but Hg had plenty of big names using it too like Mozilla. Early on (back when svn was as popular as git today) Hg had better user experience with a decent cross platform GUI tool, a more familiar CLI (for those switching from svn), and Bitbucket even let you have private repos for free which Github did not at the time. I believe part of the "git is hard" sentiment is parroting from those days since if my memory serves even git's supporters admitted that the CLI experience was a bit raw (i.e. cryptic messages). Over the years Hg's advantages would be chipped away, especially after Bitbucket added Git support and clearly favored it. As someone who supported Hg up until Atlassian dropped support I am kind of surprised Git managed to steamroll everything based on where it was. Obviously today things are very different, but I don't think we got here by any singular facet.
As far as I remember git was used because people wanted to use github, while bitbucket was more of a 'github of hg' thing. So bitbucket was only used by hg users that looked for a similar experience. The reason is probably, that early on popular OSS project were on github. Something I didn't understood (and still don't), as we just came from the aftermath of the Sourceforge disaster and I didn't want to rely on a third party again.
I only use merge. Why use a wacky feature when merge does everything I need. Rebase doesn't confuse me because I don't use it.
At least my experience has been that when using rebase you're going to be solving merge conflicts just like you would with a regular merge. Maybe you can find some more unusual cases where it gets more difficult but I've not come across those.
@@seneca983 And then suddenly, git rerere
PrimeTime is story time for software engineers.
git is not hard the issue is it is built with language that makes it confusing to a new user.
luckily this language makes it very easy to Google though
hi, new user here, confusing language in Git has triggered whole panic attacks and I was using it for a small side project
the struggle is real lmao
@@4Bakers the first time is the hardest time, it'll eventually make sense and be awesome I promise! It will help to read the documentation too though, and watch videos/ask questions to more experienced devs too! :)
This is it imho. The concepts are simple once you grasp them, but when you’ve never seen git a fjcking “git commit”, “git checkout” or “git rebase” means nothing to you intuitively.
@@_alexlazar_I feel the same. Especially as a not native speaker a lot of the words refer to concepts that I would've no idea were being used for maintaining the repo.
Git seems hard because everyone wants to learn the process instead of the architecture. They want to remember the steps, because wrapping your head around the idea of a differential audit trail or the fact that your workdir is just a bunch of diff files merged together is not immediately intuitive
Wait, is it? I thought your workdir is just whatever tree your HEAD is pointing to, unpacked.
@@MustNotContainSpaces it is. HEAD is a reference to a commit, which is just a bunch of diffs bundled together with a parent. You follow the chain until it ends, and apply the diffs in reverse
@@shaunkeys7887 a git commit references it’s parent(s), but that's only metadata and is not used to process the content of your workdir.
If it were otherwise, you couldn’t do something like a sparse checkout.
This. Git has become far far less confusing to me since I started to try and understand what actually happens when you perform the commands. Remembering the set of steps to achieve X, then another set of steps to do Y is a poor way of learning such tools. When you understand how Git works it's impossible to fuck up your branch, and even if you do you'll always know how to fix it
Well, that's the point of a tool right? I want to use my hammer to hit a nail. I don't want to take a metallurgy class to learn about how the hammer's metal is composed nor a physics class to learn about all of the forces applied. I want my tool to do it's job in the way I expect it to which git is inarguably terrible at
In school we were required to use Mercurial, svn, tortoise, cvs, and git
Just got called out!
So sorry. I've only used mercurial, svn and git
It is good to learn all options. Same with other areas of study so you will know the tools you will use when hired.
lucky you learned source control in school
I am so confused by this. Tortoise is just a client, no? There are versions for different VCSs...
Dunking on Airbnb lint and style guides. Truth!
This was interesting. I used to work for a company where the repo was in SVN, but it was very slow. Then - after a long consideration - it was migrated to HG, but they're now using GIT.
BTW CVS != CSV. Also, why use a monorepo at all?
Amazingly many people made false assumptions about the costs of stat of a million files - on local ssd this is very quick. When you try using a network drive or spinning disk or a compressed file system, things all slow down dramatically. Also caching with enough memory means local repos stat results get cached so RAM helps a lot.
But fundamentally codebases need modularisation and project separation so they don’t grow too monolithic
Wow. Git was a breath of fresh air compared to all prior source code management systems. Migrating off mercurial saved a lot of problems but mercurial itself was also an improvement on prior systems.
I don't understand why people made up this term "stacked diffs". Everything in git is a "stacked diff" in some sense, and branching off non-main branches is a core aspect of git.
I feel like people really conflate git with github, where it's the PR that creates this proclviity towards "unstacked" diffs.
I found myself having to teach coworkers git a lot, and I always begin with the directed acyclic graph thing. It's what made git click for me. When I perform git actions I actually visualize the nodes moving around.
Used git my whole career, then I moved to a massive tech company with thousands of employees and found out they used mercurial. Now they are moving (or trying to) to git and I am upset :( I like mercurial so much better then Git. It just feels easy, git feels nasty and complicated. When I go back to using Git I don't feel like I've escaped the horror, more like I'm returning to it :(
To be clear, I use git all the time and know it well including console commands etc. It doesn't mean I like it
yeah dude same. bitbucket killing hg support was brutal :(
The post got bashed on reddit.
Basically:
- the issue was niche. While git people didn't just blindly did what they were asked and instead propose better way to manage the project, fb would just not listen. On the opposite side, Mercurial people did the "promise the world" thing to get the customet.
- it is not all of facebook, just some teams
- git is easy, it is not that "you get stuck", but people think it is strange that issue arise when you don't know how a tool work.
guys how can I get informed about what Prime is up to? like he mentioned he is going to be working on HTTP on September but how can I get notified about this?
15:20 what??? sic means "written as was said"
Totally! My modern equivalent to explain it would be „something something (seriously!)”
But practically it's almost exclusively used in cases of quoting text with an error in it to note that the error was in the original and not added later. In this case, the grammar seems to be slightly off.
About git and rebasing. I found that people that do not care about other people PRs and what is going in their own project are having trouble with resolving conflicts. Becasue sometimes you need it takes a bit more than just simple merging to files to resolve the conflict. And to do that, you need to know what was the intention of the change of that other person and what is your intention for change in the code.
Well, this is going to happen in any project regardless of version control. This is more a question of collaboration than a technical question.
Yep these arent git problems but not being a prodessional dev problem
@@jhoughjr1 true, but still I found people complaing about git then, and how hard ebasing is...
i've used git since like 2011 and it wasn't til sometime earlier this year that I learned that there are 3 pieces to the puzzle: your local branch, the local repo that tracks remote, and remote repo. For a long time i'd be confused with the message 'my local branch is up to date with origin/', but that can't be true cause I knew someone just merged into remote. that message is really telling you that your local branch is up to date with the local repo, which tracks the remote repo. I got away with this for almost 15 yrs lol
yea, i think the most confusing thing about git is it's English. Especially for non native speakers like me, a lot of words are similar and interchangeable but they have completely different meanings with respect to git. If they made up their own words or used verbose commands it would be great.
@@phoneywheeze in my case i would fully attribute it from just learning on the spot and not really learning those concepts at a base level - like even though I was confused by it, it always worked, so I never really felt like I needed to make sense of it. Not until recently, when I decided that I should have a better overall understanding of my dev tools
facebook "created" stacking patches as much as git "created" diffs, lol, they just popularized a long-known good idea...
Darcs is way better for this kinda stuff, it was made in 2003, and it's still active (last release in may of 2024, as of now), and the entire point is "focus on changes rather than snapshots", where you work with changesets, not snapshot histories, you work with patches, not diffs, you can easily swap your patchsets around, or create another patch to fix a conflict, it's ideal for having a parallel workflow
Two things I don't like about rebase: With conflicts and multiple commits on the changed file, you have to solve the conflict over and over again.
You rewrite history which is why you have to force push on your feature branch. If someone else also worked on the same branch and does a pull nothing fits anymore and git proposes to merge. It the other dev then merges the changed and rebased history into his own local version it becomes fucked up.
git config --global rerere.enabled true
I've also occasionally had git bisect messed up because the commit that I was trying to find had been rebased.
honestly stacked diffs seem pretty cool. i am big supporter of using text based solutions instead of binary blobs. can always use a filesystem that is text file optimized and has anti redundancy features like git has.
Just a few:
Pull/Fetch/Checkout/Clone all different things (Pull/Fetch should be same thing w option flag)
"Checkout" means "switch branch"
A "branch" is just a pointer to a commit
"Pull request" is a push request
A branch doesn't always point to the latest commit, and neither does HEAD!
I always though of pull request as you asking someone with write access to pull your branch as you don't have write access so you can't push.
"Pull request is a push request" I've always found that strange, the wording is backwards
No, just no. "Checkout" checks out any reference. That it works on branches is just natural, but if it is confusing you just switch branches with "git switch". A branch is a pointer to a commit, true. But each commit hold info on it's parents, so there you have your "real" branch. And a PullRequest in OpenSource is actually really a pull request, because somebody with write access needs to "Pull your changes". If you work in a company with the "protected trunk/main/develop branch" method, then you could also just call it "merge" request, that's fine.
And the last sentence just underlines, that you too didn't take the afforementioned 2 hours to learn what git is... complaining that HEAD does not point to the "latest commit" (whatever that is) is just mindblowing to me :D
PS: Forgot your first point as it's crazy :D not going into pull vs fetch ... That I leave to the web based trainings you should've taken at your work :D
No, they shouldn't be the same thing...
@@microcolonel Why not? _pull -m_ for merge
Mercurial is 10x more sane in terms of UX, DX and handling data than git. That's all to know ;)
100% agree. I'm a Mercurial user as well. It's a lot easier to use and saner, with almost no way of shooting oneself in the foot. Git was designed for specific needs for maintaining the Linux kernel. It's much too convoluted and easy to screw up a repo.
@@joseoncrack Exactly, hence why I don't get Primes "you use rebase wrong" - if there's any other way than proper one to handle rebase, your tool is not UX friendly with regards to rebase.
@@d3stinYwOw I really wonder what made git so popular in the first place. How did that start? I mean, the Linux kernel is kind of a niche in the whole software industry. That project alone wouldn't have triggered such a frenzy around git. I'm always curious about what triggers popularity of tech tools.
I am a git master in intellij. I only use the cli to unblock my branch when intellij bricks my brach. Now I am no near a master on the git cli I can do basic things but I for sure can not resolve merge conflicts in the cli.
Git is easy but people don’t have a lot of life experience with directed graphs of hashed diffs.
when I transited from SVN to GIT, git was very confusing to me, I could not graps the difference between git add, git commit, git push, local and remote version of the branch.
@@albanx1 Sadly the git manual does a poor job of explaining there are FIVE different places a git command can interact with:
* stash (local)
* workspace (local)
* index (local)
* local repository
* remote repository
Lol.
Git is maybe easier when coming from SVN because it makes you appreciate all the tooling Git provides that SVN didn't. Like doing a rebase in SVN is usually organization-specific and there is no proper way to do it. You could merge trunk into your branch, or recreate your branch from trunk and merge your feature, or attempt to recreate a Git rebase by merging commits one by one. Some people write scripts to do all this, otherwise what should be a simple rebase takes a ton of time in SVN. So then you start using Git and the rebase feature is a godsend, never mind not being forced to do remote-centric version control. Can't even imagine rebase being confusing unless you're doing something insanely complicated on a regular basis.
People beware of stacked PRs with squash merges, it will mess your codebase, you have to squash merge PR 1, then interactive rebase PR 2 to drop the commits that were squashed (of course you'll have to force push), after that you can merge any way you like, including squash merge PR 2 (unless you have a 3rd stacked PR, in such case you start over).
git felt hard when I was learning it, but once I learned what all the commands where it immediately stopped being confusing. Git is not hard, its just a lot of commands to memorize for the new git user
Git's not hard, most of the people who know git are just absolutely fucking terrible at explaining how it works to someone who doesn't know it at all.
I think you've isolated the core issue; I've thought that a lot of confusion from git comes from people describing the system by using inaccurate language and ambiguous prepositions, which don't really make sense. For example, people often say things like "merge the feature onto master", which doesn't fit the meaning of "merge", as it would be correctly be "merge the feature _with_ master". And then there are boutique verbs like "rebase" or "diff" (a noun actually?) that don't really fit into English sentences.
There are tons of other examples, and often the people explaining procedures don't really understand the tool themselves, so they are forced to describe the process vaguely.
I think why a lot of new-ish developers aren't getting git 100%, is that a single dev, freelance or hobby oftentimes aren't cooperating with other people on larger projects, and typically only need to add, commit and push. A single dev working on something don't have to make a separate branch for a feature, they can work all they want on main where no merging is needed, and simply push it when it's done and testet locally. They simply aren't used to other people messing around in the code base, leading to conflicts *insert possum don't touch my garbage meme*
I'm with you that git is overall pretty good. However, there are definitely areas where it's not truly user friendly. In general, command line tools aren't too user friendly, since the --help command usually doesn't tell you "these are the most common things you are going to want to do and the syntax for those, but if you need something more advance, there are these commands and options, too:" and instead you need to spend a lot of mental processing cycles on figuring that out what are the 2-3 commands you are actually going to be using most and how to use them.
Then there are common flows like rebasing where they actually require knowledge of --force flags, which come with drawbacks. If that is supposed to be a common flow, the drawbacks should have been mitigated earlier, but the --force-with-lease flag didn't exist until much later and the -f flag doesn't use that. There's also an even newer option called --force-if-includes, and from a first-time user perspective, this is a really confusing API. Naming-wise, the existence of branch and checkout commands (which the latter actually creates a branch, too) is not the best. That's why the switch command was added in newer versions of git, but you still have all of the old commands available, older tutorials are still going to tell you about older methods, and as a new user you're going to have to figure out how to filter through a lot of old information to really figure out how to use the tool.
That's not to mention that merge conflicts are still, IMO, most easily handled via UI and IDEs. Resolving them in the cases where there was an overlap in development at all tends to not be easy and I find myself frequently having to edit by hand and then compile and retest the code. Even sometimes in cases where the changed lines were side-by-side and not truly changing the same code.
It could for sure be a lot worse, but I feel like you basically can't easily learn to use git from git itself and have to rely on a lot of external tutorials and tooling to actually use it in a reasonable fashion.
Stream chat reeks of Dunning Kruger and skill issue, but then again which twitch chat doesn't? Literally most of those arguments are "git sucks because it sucks", one person made a good comment about scalability at monstrously large codebases which isn't an issue for 99% of people and companies.
Thank you Prime for voicing the "Git is easy. Just spend the minimal effort to learn its basics and you won't be confused"
I'm known as the git expert at my company. I think most of my peers just learn the basic commands and google their way out. Which is how we do most of coding. However, all I did was watch a few videos on Git and practiced and instead of relying on commands they told me to run, I applied the knowledge I knew to do what I felt made sense.
I don't want to say it's easy but I certainly think every programmer can solve most issues if they put that extra effort in.
I'm the resident "git expert" at my work. Everyone uses Source Tree to do their work. Meanwhile I do my git stuff off the command line. Whenever they have an issue, I make them pop open the terminal, and teach them the commands.
Some of them still refuse to just adopt CLI. Many of the reasons I'm good with Git and fix almost any problem is because I use the CLI. Don't know a command? 'git [command] --help' is all you need to put in to get the docs.
Afterwords it is a matter of just picking a diff tool and binding it. You can do a few more other customizations like shortcuts but I barely use them. Tab completion is good enough and my processes are just commit and add files with occasional pull for updates.
@@ChrisCarlos64 The CLI feels better for many things but trying to do things like line staging in the CLI is comparatively kinda painful. Also exploring the history is much better with an actual graphical visualization of the commit graph.
I've been using it for over 10 years, read man pages many times, and I still think it's confusing.
Mercurial was great and I preferred it over git when they both started gaining popularity, I'm a little sad git won, but github is a better name than hghug
Git is one of those things that makes a lot of sense once you understand it, but it's a lot to learn before you understand it and feel confident. My team has been with me for FOUR YEARS and they still don't quite understand how feature branches work. It's actually so simple, but somehow it still confuses them. And I understand because coming from TFS it was a lot of extra stuff to learn.
Git is not hard, but it goes in the way of devs instead of just working. People don’t want to spend hours learning version control, they want to actually code.
Who spend hours learning git?
This stupid logic could be applied to any tool. But it’s stupid
@@vilian9185 bro just launched entire course on git, and you still doubt that.
@@paul_w I agree on this one. With a power tool e. g. I know what its used for. And I really do need a drill. With git its always kinda the same "everybody uses it, so you must too"
Weird take. Most things in our industry is hard and you need to learn them because they are essential to programming.
The build system, the version control, ci pipelines, test frameworks, containers, config files etc. There are a million things that we need to know you will never get to the place where you can just write some logic and be done for the day.
We write in c++ and I always tell people the easiest part of our job is writing in c++. It is everything surrounding it that is difficult because it is there you can have actual errors and slowdown in productivity.
This channel doesn't miss a chance to spread FUD about Python. Object oriented programming in Python is wonderful. And if you disagree, you can go back to pulling your hair out trying to write a GUI in Rust.
Did the build your own git code crafters challenge and it cleared so much basics for me, now i dont feel confused with complicated git concepts either
more people should learn about stuff like DARCS that do MASSIVELY different approach to version control than git
I had to stop and think for a moment how the hell one guy wrote a version control system from scratch with no tutorial on how in 5 days. That is seriously incredible. I didn't know it was that quick.
Just don't mono repo. It stops scaling eventually - doesn't matter if its Git, Mercurial or something else.. It's like vertical scaling hardware. You can do that for a while but it will stop to work eventually.
Back when we used svn we had a monorepo for all stuff in the company (small company though). As svn allows you to checkout subtrees it was no problem, each project had it's own tree. But it made it incredibly easy to use parts of code from another project, as it was the same repo you could svn copy it. Monorepos have their advantages. We never had performance and scaling issues as well, but yes, we aren't exactly Google.
@@Mnementh-ub8mdthe only ones having issues with monorepos is git-heads. so their solution is to announce monorepos an anti-pattern, unscalable and other fud.
It might not if you're a small company.
Pijul handles most operations fine at scale, just not record (what most ones call commit) because it still has to check every file for changes.
I'm shocked that Prime is so surprised at the idea of 14 million files being realistic. I work at Meta, we have *easily* more than 14 million files in the mobile repo alone.
Can someone explain why you'd have millions of files in a repo? What possible benefit could that have over splitting this Galactus-sized mono-repo up into smaller repos? Also why do you need to care to version track millions of files? I'm having a hard time imagining that this would be necessary but I'm curious and open to any answers.
I do come from the embedded software world, so maybe this is a web dev thing. 🤷♀ For me, most files are only generated for a build and then no longer necessary afterwards, so the core repo is far fewer in size.
have all developers always have access to all existing code. To learn and follow similar practices
@@aqua_pi Thanks for replying! I see some of what you mean, but...
Hmm... Well, in my company, a group of developers are given access to all repositories in a give GitHub organization. So you can still have access to repositories split up.
And following similar practices comes from 1) clearly documenting coding standards and expectations somewhere, 2) ensuring code standards are maintained already, regardless of where you look; 3) having project seniors enforce those on PRs and other code reviews; and 4) good organizational training/education.
@TenFrenchMathematiciansInACoatwhat? no. fb main repo has everything from data infra services to network switch custom firmware. the size primogen found laughably unrealistic turned out to be underestimated fairly soon. it’s not hard to get to this size once you do your own custom everything from compilers to kernel, and there are serious benefits when working collaboratively and the core / products have certain dependencies.
Look up advantages of monorepos
Git is only hard for people who can't resolve merge conflicts. Here's a fun story involving merge conflicts that happened at my previous job: I was hired as a senior frontend dev (React) and we were staring some new projects I have created the frontend repo for the first project and setup the structure of the project, a readme file for instructions (since other devs were juniors and they never used react) and some basic CI/CD pipelines. The team leader comes from her vacation and the first thing she does is to ask the devops to downgrade my access to "developer" because "she is capable of maintaining the repos herself and will handle merge conflicts" (she's not my superior btw, just some weird corporate hierarchy). Comes first merge conflict, she couldn't do anything for 3 days and then asks the devops to make me a maintainer so that I could resolve the conflict :v
Wow so her masters in conflict resolution wasn’t applicable ?
not only large-scale repos (in terms of the number of files) can be a problem, but also repos stored on remotely mounted file systems.
the slowness is proportional to both the I/O latency and the number of I/O calls.
that's not an SCM problem tho
@@kyjo72682 it is, in a way. if there is a significant number of I/O calls (such as stat) that the program has to make to complete an operation, then it will feel slow if the file system has high latency. the lower the number of i/o calls, the better.
As a git user the biggest thing that makes it hard for me is the absence of Magit for Mercurial. The other smaller issue is that git felt at least from my pov simpler but more complex when going further.
How do you do `hg cp` in git? It preserves blame in a way that looks like a move, but also preserves the original.
I would never consider taking any advice from facebook.
@TenFrenchMathematiciansInACoatGreat company, shitty software.
@TenFrenchMathematiciansInACoat gargle writes some of the worst C++ out there yet one of their core public-facing C++ products (chromium) is one of the most successful pieces of software in existence. This despite being objectively terrible in both code quality and functionality.
@TenFrenchMathematiciansInACoat If that logic made any sense chrome wouldn't be the most successful browser.
@TenFrenchMathematiciansInACoat I understand the argument, it's also true of Microsoft and their MS-DOS and later Windows operating systems. The industry doesn't like them. Still they owned everyone at some points and made quite some money. On technical grounds it's another story, like usual.
@TenFrenchMathematiciansInACoat Yes, I'm not a fan of PHP. Beside, I've never used their website, not once in my life. I've heard it was "has-been" after ten years of existence or something. The only good point of Facebook is probably they have a guy who contributes to GCC. I do use GCC, so there is that.
I've seen videos about how deleting private git code doesn't delete it from the public, in some cases.
Something to do with the assumption people make of what 'private' means.
That's it I'm doing ur git course prime. It's my one major weakness still
I have done the full cycle. I have used RCS, CVS, Subversion, and git. I briefly worked on a project that used hg but was only pulling code from that repo. I still use RCS at times and prefer Subversion for personal projects. git is ok until you have to deal with a merge conflict or find you have multiple stashed changes. At that point you need a deeper dive in to how to use git. Git is the only VCS that has resulted in me losing unsaved changes that I had to redo from scratch. While learning git I had to create my own cheat sheet on how to use it. Currently it is over a full page long. I only use git because Open Source projects I contribute to use it. If not for that I would stay away from it.
The git client is hard, not git. There's a reason that there are a million paid tools to interface with git. If you look at git docs there are several ways to do things and they all have several possible parameters, and their explanations tend to be very technical, creating situations where you open the docs with one question and leave with many more. I absolutely hate when I have to use git directly, even though I love that when I have to it does have everything I need to fix whatever problem I'm having.
TLDR: I think git docs need a "basic" version, with the most common commands already with the most common parameters, followed by explanations that are way less technical than what it has right now, and an advanced version that throws the book at you - what it has right now. That's what paid git tools are offering, shortcuts to routine operations.
That's not how TLDRs' work!
Simple question: are you too stupid to use git? It’s so simple and well defined that if the answer is yes, you’re probably incapable of doing your job either. Skill issue. A huge one. Like all those “I only use gui” pussy “programmers”
A btw if you need a paid tool to create a shortcut for yourself… i mean… pathetic
Google last time I checked is still using an enormous monorepo. Which they insist is more efficient, but I frankly think it's cope. I'm sure with the tooling it's about equal, but I think they could've easily converted to git and been fine had they done it early enough.
git isn't hard. but solving issues can be absolute hell. +1 pain if the person you're working with does not understand git, which is 60% of the time. +1 pain if there is a person going crazy with its advanced functions where i find my local behind remote in so many things.
Git is not hard, the hard part is when people use it in a way that makes it difficult sometimes to work with
I have lots of coworkers struggling with git and I thought about why, ans my conclusion was, that they started off with a GUI tool which does multiple git commands in background per click, and they never really tried to learn git commands. An then those people tell freshers stuff like "never use rebase, it is weired and destroys everything" who will then also struggle. I started off the same way and I'd say, I'm not a shell only guy, but when it comes to git, I really enjoy using CLI instead of any GUI.
Spot on reasoning.
The amount of times our senior dev has to ask the other senior dev for help with git makes me feel way better about myself.
I've survived rcs, cvs, mks, svn, vss and yes hg - loved it - only switched to git when Atlassian abandoned hg
Microsoft made a series of patches to git to make it monorepo friendly, you know, they are also a big monorepo user.
Perforce here, and I've always much preferred its P4V GUI utility - would really like to see that re-adopted/factored for Git honestly. Aside from its Flow & Layout, its default Hotkeys just felt better/more natural e.g. select changed file and Ctrl+D for its Diff presented graphically, and even editable in it too.
I'm not familiar with P4V GUI, but there are tons of different GUI interfaces for Git besides the official one, maybe you'd be interested in giving them a try
I was using mercurial and bazaar before moving to git and it was really a bliss to start get responses from any version control commands in few hundred milliseconds (using git) instead of few seconds on python based version controls. Maybe those people who cared about it in facebook just kept using git for their work and used adapter to push their code finally to mercurial when it was really necessary to push to remote 🤷♂
Hg is the same as git just with better branch management.
And Prime, do you actually think a million file repo is rare? Companies that use perforce or clearcase are usually giant monorepos.
I used SVN and then git. For seemed complicated at first, but my word is SO MUCH SIMPLER
0:17 "Muh-curial"??? Bro why do Americans keep dropping the "R" like that? You guys did the same with "Turmeric". The "Murica" runs deep! 😂😂😂
That file checkout and it comes back issue happens when you have a file named something like AAA.json and aaa.json committed into the repo from a computer with a case sensitive filesystem and then you try and handle those files in git on a case insensitive filesystem like on a Mac.
Microsoft switched windows source over to git and solved the massive file sizes and added support for partial downloads so that not every developer needed multiple GB of source.
So yes GIT today can handle very very big code bases.