10 ms·

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to ha

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare to use on a team for any serious work. Git has no such problem. There’s nothing it can’t do. Instead, the only limitation is on the user being able to know how to get Git to do what they want it to do. Thankfully, that’s always solvable with a quick read of the documentation or web search. I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. If you abstract away the power, you are no longer solving all the problems that Git solved. People just don’t realize what problems are being solved because they never lived through those problems with the previous VCSes. You know what’s easier than building a new VCS better than Git? You know what’s easier than using a different VCS from the rest of the world? You know what’s easier than designing a miraculous abstraction on top of Git? Learning Git. Whatever effort you are putting into seeking or building an alternative, instead put that effort towards becoming a Git expert. It will be a lot less effort with a lot more benefit. Trust me on this. It will be well worth it for your career and for your personal computing life as well.

bryanlarsen 3y ago
The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git. Totally agree on your main point though. The benefits of switching are far lower than the costs.
- tehbeard 3y ago
  > ..because it saves snapshots rather than changes.. I might be misremembering the technical details, but isn't that only the case in a git repo with zero pack files? Will grant that the lack of metadata on renames can be issue when a file is heavily refactored alongside it's relocation.
  - bryanlarsen 3y ago
    https://en.m.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.m.wikibooks.org/wiki/Understanding_Darcs/Patch_th...
- mikewarot 3y ago
  >it saves snapshots rather than changes Once you understand this, GIT makes a whole lot more sense. The trouble with failed merges is an artifact of trying to appear like it tracks deltas. Merge conflicts when you're the only programmer on a product (but have multiple computers) are maddening. I blew away .git and everything in it, restarting a repository, more than once because I couldn't resolve a merge conflict, before I learned that simple fact. I've got from .zip files of my source code on floppy disks, to SVN, then Mercurial, and finally GIT. GIT is amazing, though the UI is a pain, as most agree.
- rendall 3y ago
  > doesn't capture some metadata changes like renames If you rename the file using git and that is the only change in your file, then it works: git mv oldfile newfile Commit that change and the rename is in your history.
  - blibble 3y ago
    the rename won't be in your history because the tree and commit objects don't support renames the tooling infers a rename based on the lack of a content change
    - trevyn 3y ago
      Is there a difference?
      - phyzome 3y ago
        Absolutely. In a move-and-edit situation, git will sometimes infer a rename and sometimes not, based on your local version of git, your settings, and the details of the edit. If inference fails, you may have a harder time resolving merge conflicts, performing cherry-picks, etc.
        trevyn 3y ago
        So just make sure the moves and edits are in separate commits?
        phyzome 3y ago
        Yes, that's the standard workaround.
        deleted 3y ago
        [deleted]
      - dafelst 3y ago
        Absolutely, the inference is based on a set of heuristics and is often just plain wrong.
- kevincox 3y ago
  Not only merge conflicts I find that this causes trouble if you need to manage multiple branches. Generally you see patterns like 1. Create patch 2. Merge to main branch 3. Backport a cherry pick. But there is no machine-readable metadata that the commit is the same in both cases. In simple cases you can work around this by basing the patch off of the merge base but if there are conflicts that doesn't work well. The result of this is that these two different but logically identically commits will cause future merge conflicts and make questions like "does this branch have this patch" much more difficult to answer. This is something that I think https://pijul.org/ https://pijul.org/ does quite well. Their base unit is a patch and that can be applied to multiple places. You can also have snapshots which are logically a collection of patches.
- gitaarik 3y ago
  Don't the snapshots make it much faster than without?
flohofwoe 3y ago
Git keeps the entire history on your local machine, this becomes a problem if your project grows to several hundred GB (not untypical in game dev). Even SVN was much better for working with large repositories, you only needed a big server. Git is quite nice for "source code only projects though".
- syndicatedjelly 3y ago
  Does Git LFS help with this problem?
  - robaato 3y ago
    Have seen various teams have major issues with LFS - becoming quite a support overhead to keep art teams productive.
    - flohofwoe 3y ago
      Yeah exactly this. Git LFS is supposed to fix the problem, but I haven't seen it working flawlessly either yet.
    - syndicatedjelly 3y ago
      Interesting, I had issues using Git LFS to store images for my personal site. I thought I just didn't know how to use it properly...
  - jzl 3y ago
    Not Git LFS, but Git VFS, now replaced by “Scalar”: https://github.com/microsoft/scalar https://github.com/microsoft/scalar
  - sireat 3y ago
    Overall LFS feels a very hacky tacked on solution with warts. Git LFS is horrible if you mistakenly add some file(s) to LFS. Restoring to LFS-less state is supposed to be easy but it is always very painful. There should be a way to tell repo - I do not want any LFS at all. In practice this is painful, and it is easier to start a new repo.... Also for some reason Github/Microsoft decided to "monetize" LFS. The freebie limits are 1GB for hosting AND transfer! Then the charges get very expensive. I am not sure why Github LFS is priced like some AWS S3 plan not OneDrive plan.
tester756 3y ago
>I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. I disagree, really. There is not fundamental reason why you cannot have user-friendly UI for 98% of the cases and some "advanced" for those 2%. Just like GUIs have "advanced" settings, the CLI can have well designed 10 commands for basic usage that are taught to newbies and then advanced ones.
- Apreche 3y ago
  Do it then. Many have tried. All have failed. Talk is cheap.
  - tester756 3y ago
    >Do it then. Many have tried. All have failed. Talk is cheap. I'm, just like many other people using GitHub Desktop (or Git Kraken or Git Extension, but I dont like this one) when I'm working in GUI environment, that's proof that it is possible. The problem with creating 3rd party tool that's CLI wrapper is that you cannot rely on it being installed on the system. That's why such solutions usually fail - because you risk relying on stuff that may not get traction and you'd be better sticking to "official" syntax in long run.
    - karmakaze 3y ago
      Is gitk still a thing that's available with git? Not as full featured but great for viewing and good with many commits/files.
      - EstanislaoStan 3y ago
        Yes
    - namtab00 3y ago
      I'll share here my positive opinion of GitExtensions (on Windows). It has really helped me use and better understand Git, while also helping me define and share workflows with my colleagues.. Other GUIs, like the ones embedded in VisualStudio, VSCode or Rider, try to sell skipping some cognitive steps for some operations as simplifying or speeding up dev flow. I find they are just offering extra (beyond what git itself offers) ways of shooting yourself in the foot.
jampekka 3y ago
> I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. There's a lot of "useless" complexity in the Git UI. The naming of the commands and the underlying concepts are quite inconsistent. The commands themselves are inconsistent. It's rare to see somebody, even git fans, to dispute that the UI is far from optimal. And the warts in the UI are being improved. These UI warts start to become invisible when you get used to them, but e.g. when teaching git they become painfully obvious again. The underlying git architecture is simple and it's the simplicity that makes git powerful. Powerful tools don't necessarily need complex interfaces. In fact power often comes from simple interfaces that compose well.
- mejutoco 3y ago
  We could get aliases that get slowly incorporated into git. Like, let's say git undo instead of git reflog, or things like that. It would not be too difficult to support a couple of names to do the same thing and let people use the one they prefer.
  - jampekka 3y ago
    We are slowly getting those. For example there's now git restore (and git switch) to fix the god-awful overloaded checkout. When you get your repo into a state that needs reflog, it's probably not amenable to very straightforward commands. A bigger problem is that it's a bit "too easy" to get into that kind of state. The original git interface wasn't really intended for "general use" and there was supposed to be the friendlier "porcelain" on top of the lower level "plumbing". But people started to use the plumbing directly and the porcelain never came to be.
dafelst 3y ago
While I feel like this is generally true for most programmers and knowledge workers, Git is absolutely not suited to the workflow of several industries, including the one I work in: games. Working with an engine like Unreal Engine for a project of any reasonable size requires working with both hundreds of thousands of active files (my current project's repo's HEAD has ~400k) and hundreds of gigabytes of active files, many of which are many GB on their own. Our repository (in perforce) is currently in the order of 10TB. Git, even with LFS and partial clone and shallow copies and fsnotify just falls apart at this scale. Add to that the necessity for less-technical people (artists, designers, VFX, audio, etc) to use it, and it is really just a non starter. I absolutely loathe Perforce (having used and occasionally admin'd it professionally since 2007), but I begrudgingly admit that is is currently the only publicly available VCS that can fulfill all of the requirements of this industry in a practical way. Plastic and the others just aren't there yet.
- karmakaze 3y ago
  This could be solved with references rather than copies if your tools integrated them. e.g. dependencies can be ref'd with source/name and version. To ensure availability all such used blobs could be stored efficiently elsewhere and versioned. It's great that Perforce works and I've heard others in the graphics field using it, so it satisfies a need. Don't know if/when it would be a general need for say GitHub users.
- firesteelrain 3y ago
  That’s why you need a binary repository like Artifactory and not store your large files in Git. But you can still track them in Git with the large files in a binary repository like Artifactory.
- withinboredom 3y ago
  This is a solved problem with git. I’ve worked on bigger projects than yours with histories that are so big you can’t clone them if you wanted to. I’ll make a note to drop what to google for tomorrow, but basically the history is fully available but git knows how to query it over the network. When you open a file, it loads it over the network. Remote build systems do your builds. Most of this was built by Microsoft to work on Windows with git. We moved from SVN in the late 2010’s, and holy crap man, did it change our workflows. No longer were we passing around patch files in a team for code reviews, but actually reviewing code somewhat like on GitHub. It was magical.
agumonkey 3y ago
That's what i liked about git too. It felt like a powerful, ready to use tool. CVS and SVN were more bureaucratic, slower and limited. Took zero second for me to drop everything else. The underlying model is alien to many, it requires non black box approach to get out of pits sometimes but to me it's always worth knowing. The only decision I dislike about git is the soldered staging area idea. There's a reason why most people end up stashing 109 times a day, and I think there's a golden idea in merging the two
cflewis 3y ago
This post is a terrible failure of imagination that would make one stop language development as C because it was so much better than Assembly. If you have no problems with Git, then I’m happy for you. I certainly have problems with Git, eg its inability to handle large repositories meaningfully (enjoy a Chromium checkout!), the arcane CLI commands, the shut-your-eyes-and-hope of moving commits between branches and other sharp edges. That Git has been as resilient as it has is largely a function of being written by Torvalds and GitHub network effects. It isn’t for lack of better/as good features found in other VCS methodologies.
- penguin_booze 3y ago
  > its inability to handle large repositories meaningfully Out of curiousity, what other SCM tools can pull this off better?
  - cflewis 3y ago
    I haven’t played with many because I simply don’t have the time between work (Google’s Piper and Git) and kids. Piper handles the monorepo by only offering files when requested by the file system at the specified commit (this is probably a gross or even incorrect simplification, but is how it presents to the user). There are good reasons that one should keep the whole commit history to distribute a source of truth, but at the same time if one is going to place full trust in something like GitHub (as many do), there’s no reason that full trust can’t be given to a similar website that provides a Piper model with some mechanism to request more than one commit to be brought to local storage (to get more sources of truth). End of the day, a large repo checkout is going to be limited by either your network, your CPU/storage to perform archive expansions, or frequently both. I get the impression that Android and Chromium are expanding faster than those other things are improving, but have no data to back that up.
  - slalomskiing 3y ago
    Almost every big game studio uses Perforce
- sroussey 3y ago
nunez 3y ago
Wholeheartedly agree. Going from SVN to Mercurial was a night and day experience. Going from Mercurial to Git was a marginal improvement initially but a lasting change long-term. Then there are the "visual" VCSes like Rational and TFS that are designed to _only_ work within an IDE and grokking them involves wading through hundreds of pages of corporate tech docs. VCSes (or at least the ones I used) were generally awful before Git.
em-bee 3y ago
i mostly agree that git can do almost anything (but see the limitations others bring up), however this claim is easy to disprove: Whatever effort you are putting into seeking or building an alternative, instead put that effort towards becoming a Git expert. building an alternative naturally is more work than to learn git for one person, but not everyone needs to do that. a few people building an alternative could save the learning effort of many more people. instead i'd like to point out a different reason why rebuilding git may not solve the problem: git is good because it is powerful and flexible. that power and flexibility by necessity makes git more complex and difficult to use. you can build a simpler system, but then half of todays git users won't be able to use it because it won't have the features they need. and a system that has all the features of git today and also solves the problems it currently has will be even more complex and less straigt forward to use. the best approach is probably to have a common backend that has all the power and flexibility needed, and multiple different frontends that are simplified to only expose the features needed for a particular workflow.
mlsu 3y ago
All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Git solves the deeply complex problem of distributed version control. Most complaints about git are actually complaints about the essential complexity of the problem, not the accidental complexity of the tool used to solve it.
- jltsiren 3y ago
  Most complaints about git are about the design philosophy of the tool. While there are complex edge cases in distributed version control, the vast majority of situations people actually encounter are not that complex. But because git prioritizes the worst case over the typical case, it's much less usable than it could be.
- baazaa 3y ago
  Totally agree that people spend way too much time complaining about git's solutions but there's not nearly enough criticism of the fact it's solving the wrong problem 99% of the time. I want to share 5k LOC with a colleague. Anyone who thinks that requires a decentralised solution in 2023 is unwell. I recently wasted a few hours because I forgot to fetch before running some code. Sure the UI could be better (if you're very tired and you're told you're up-to-date you'll stupidly believe it), but fundamentally the 'feature' that caused this problem is something I'll never use. I'm always going to code with a connection to the internet. I shouldn't need to mentally keep track of local vs remote because that distinction simply shouldn't exist.
  - yencabulator 3y ago
    What you fail to understand is that, outside of all talk about decentralization, keeping local state is a huge performance optimization. Tagging a large CVS tree used to take several minutes, because it would talk to the remote server separately about every file. History browsing & bisect are very pleasant in Git because the local computer already has all the information, and just needs to present it to you.
Affric 3y ago
Great comment. Git really needs a good git tutor game. Like vim tutor or any one of the n*x/shell games.
deleted 3y ago
[deleted]
grecy 3y ago
> I’m old enough to have used RCS, CVS, SVN, then finally Git I'm old enough to have used CVS, SVN and then a bit of git. I remember the big selling point to go from CVS to SNV was "you can put binaries in there!" ... which we never did. And now I see the selling point to go from SNV to Git is "you can do really complicated stuff like rebase".... which we've never done. For a team who just does run of the mill distributed version control stuff (commits, diffs, blame, conflict resolution), can you explain why git is such a huge benefit over SVN?
- gitaarik 3y ago
  SVN doesn't do very good conflict resolution. It especially becomes more of a problem when you have multiple people working on several branches, that might want to merge some of each other's work. Apart from this, git also came with many more advanced features that improves branch and history management.
darose 3y ago
> Git has no such problem. There’s nothing it can’t do. It can't display me the branch I'm working on, starting from the commit that began the branch, until the last commit. (Or if it can, I have no idea how to do it.) This isn't a functionality issue, but rather a conceptual one. Git just fundamentally thinks of branches differently than I do. (And, maybe most humans?) To me, a branch begins ... when I branch it. To git, a branch begins ... at the very first commit ever in the repo, since they consider commits that were made before the branch point to still be part of the branch. The branch point then is just another commit to git - and not even one that they think is important enough to highlight. But without any ability to clearly identify the branch point, you can often find yourself looking through a forest of commits that are irrelevant to what you're really searching for. I spent the better part of an hour the other day trying to figure out how to identify my branch point. (For the record, the best solution I eventually found was: cat .git/refs/heads/<branch name>.) Just my $0.02, of course, but IMO this is absurd - and a big feature gap / user friendliness issue with git compared to other VCS's. IMO git is just another step in the evolution of VCS's, and not necessarily even one of the better ones. Its concepts, functionality, and feature set are focused primarily on distributed development and multiple people maintaining different source trees ... which is fine for the Linux kernel and other projects that heavily use that use case. But many/most projects don't work that way, and for them a centralized VCS is sufficient. I have no doubt that a better VCS will come along and replace git one day.
- kmacleod 3y ago
  git log <base-branch>..<branch> I often need the count of commits, usually for build IDs, git rev-list --count <branch> ^<base-branch> I usually use gitk for visualizing branch commits. CLI equivalent is git log --graph --oneline --all
  - liveoneggs 3y ago
    he is saying that finding <base-branch> is too hard. There is probably some magic with git merge-base or git show-branch but I don't know them well enough to do it

bryanlarsen 3y ago

The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git. Totally agree on your main point though. The benefits of switching are far lower than the costs.

tehbeard 3y ago
> ..because it saves snapshots rather than changes.. I might be misremembering the technical details, but isn't that only the case in a git repo with zero pack files? Will grant that the lack of metadata on renames can be issue when a file is heavily refactored alongside it's relocation.
- bryanlarsen 3y ago
  https://en.m.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.m.wikibooks.org/wiki/Understanding_Darcs/Patch_th...
mikewarot 3y ago
>it saves snapshots rather than changes Once you understand this, GIT makes a whole lot more sense. The trouble with failed merges is an artifact of trying to appear like it tracks deltas. Merge conflicts when you're the only programmer on a product (but have multiple computers) are maddening. I blew away .git and everything in it, restarting a repository, more than once because I couldn't resolve a merge conflict, before I learned that simple fact. I've got from .zip files of my source code on floppy disks, to SVN, then Mercurial, and finally GIT. GIT is amazing, though the UI is a pain, as most agree.
rendall 3y ago
> doesn't capture some metadata changes like renames If you rename the file using git and that is the only change in your file, then it works: git mv oldfile newfile Commit that change and the rename is in your history.
- blibble 3y ago
  the rename won't be in your history because the tree and commit objects don't support renames the tooling infers a rename based on the lack of a content change
  - trevyn 3y ago
    Is there a difference?
    - phyzome 3y ago
      Absolutely. In a move-and-edit situation, git will sometimes infer a rename and sometimes not, based on your local version of git, your settings, and the details of the edit. If inference fails, you may have a harder time resolving merge conflicts, performing cherry-picks, etc.
      - trevyn 3y ago
        So just make sure the moves and edits are in separate commits?
        phyzome 3y ago
        Yes, that's the standard workaround.
      - deleted 3y ago
        [deleted]
    - dafelst 3y ago
      Absolutely, the inference is based on a set of heuristics and is often just plain wrong.
kevincox 3y ago
Not only merge conflicts I find that this causes trouble if you need to manage multiple branches. Generally you see patterns like 1. Create patch 2. Merge to main branch 3. Backport a cherry pick. But there is no machine-readable metadata that the commit is the same in both cases. In simple cases you can work around this by basing the patch off of the merge base but if there are conflicts that doesn't work well. The result of this is that these two different but logically identically commits will cause future merge conflicts and make questions like "does this branch have this patch" much more difficult to answer. This is something that I think https://pijul.org/ https://pijul.org/ does quite well. Their base unit is a patch and that can be applied to multiple places. You can also have snapshots which are logically a collection of patches.
gitaarik 3y ago
Don't the snapshots make it much faster than without?

flohofwoe 3y ago

Git keeps the entire history on your local machine, this becomes a problem if your project grows to several hundred GB (not untypical in game dev). Even SVN was much better for working with large repositories, you only needed a big server. Git is quite nice for "source code only projects though".

syndicatedjelly 3y ago
Does Git LFS help with this problem?
- robaato 3y ago
  Have seen various teams have major issues with LFS - becoming quite a support overhead to keep art teams productive.
  - flohofwoe 3y ago
    Yeah exactly this. Git LFS is supposed to fix the problem, but I haven't seen it working flawlessly either yet.
  - syndicatedjelly 3y ago
    Interesting, I had issues using Git LFS to store images for my personal site. I thought I just didn't know how to use it properly...
- jzl 3y ago
  Not Git LFS, but Git VFS, now replaced by “Scalar”: https://github.com/microsoft/scalar https://github.com/microsoft/scalar
- sireat 3y ago
  Overall LFS feels a very hacky tacked on solution with warts. Git LFS is horrible if you mistakenly add some file(s) to LFS. Restoring to LFS-less state is supposed to be easy but it is always very painful. There should be a way to tell repo - I do not want any LFS at all. In practice this is painful, and it is easier to start a new repo.... Also for some reason Github/Microsoft decided to "monetize" LFS. The freebie limits are 1GB for hosting AND transfer! Then the charges get very expensive. I am not sure why Github LFS is priced like some AWS S3 plan not OneDrive plan.

tester756 3y ago

>I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. I disagree, really. There is not fundamental reason why you cannot have user-friendly UI for 98% of the cases and some "advanced" for those 2%. Just like GUIs have "advanced" settings, the CLI can have well designed 10 commands for basic usage that are taught to newbies and then advanced ones.

Apreche 3y ago
Do it then. Many have tried. All have failed. Talk is cheap.
- tester756 3y ago
  >Do it then. Many have tried. All have failed. Talk is cheap. I'm, just like many other people using GitHub Desktop (or Git Kraken or Git Extension, but I dont like this one) when I'm working in GUI environment, that's proof that it is possible. The problem with creating 3rd party tool that's CLI wrapper is that you cannot rely on it being installed on the system. That's why such solutions usually fail - because you risk relying on stuff that may not get traction and you'd be better sticking to "official" syntax in long run.
  - karmakaze 3y ago
    Is gitk still a thing that's available with git? Not as full featured but great for viewing and good with many commits/files.
    - EstanislaoStan 3y ago
      Yes
  - namtab00 3y ago
    I'll share here my positive opinion of GitExtensions (on Windows). It has really helped me use and better understand Git, while also helping me define and share workflows with my colleagues.. Other GUIs, like the ones embedded in VisualStudio, VSCode or Rider, try to sell skipping some cognitive steps for some operations as simplifying or speeding up dev flow. I find they are just offering extra (beyond what git itself offers) ways of shooting yourself in the foot.

jampekka 3y ago

> I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. There's a lot of "useless" complexity in the Git UI. The naming of the commands and the underlying concepts are quite inconsistent. The commands themselves are inconsistent. It's rare to see somebody, even git fans, to dispute that the UI is far from optimal. And the warts in the UI are being improved. These UI warts start to become invisible when you get used to them, but e.g. when teaching git they become painfully obvious again. The underlying git architecture is simple and it's the simplicity that makes git powerful. Powerful tools don't necessarily need complex interfaces. In fact power often comes from simple interfaces that compose well.

mejutoco 3y ago
We could get aliases that get slowly incorporated into git. Like, let's say git undo instead of git reflog, or things like that. It would not be too difficult to support a couple of names to do the same thing and let people use the one they prefer.
- jampekka 3y ago
  We are slowly getting those. For example there's now git restore (and git switch) to fix the god-awful overloaded checkout. When you get your repo into a state that needs reflog, it's probably not amenable to very straightforward commands. A bigger problem is that it's a bit "too easy" to get into that kind of state. The original git interface wasn't really intended for "general use" and there was supposed to be the friendlier "porcelain" on top of the lower level "plumbing". But people started to use the plumbing directly and the porcelain never came to be.

dafelst 3y ago

While I feel like this is generally true for most programmers and knowledge workers, Git is absolutely not suited to the workflow of several industries, including the one I work in: games. Working with an engine like Unreal Engine for a project of any reasonable size requires working with both hundreds of thousands of active files (my current project's repo's HEAD has ~400k) and hundreds of gigabytes of active files, many of which are many GB on their own. Our repository (in perforce) is currently in the order of 10TB. Git, even with LFS and partial clone and shallow copies and fsnotify just falls apart at this scale. Add to that the necessity for less-technical people (artists, designers, VFX, audio, etc) to use it, and it is really just a non starter. I absolutely loathe Perforce (having used and occasionally admin'd it professionally since 2007), but I begrudgingly admit that is is currently the only publicly available VCS that can fulfill all of the requirements of this industry in a practical way. Plastic and the others just aren't there yet.

karmakaze 3y ago
This could be solved with references rather than copies if your tools integrated them. e.g. dependencies can be ref'd with source/name and version. To ensure availability all such used blobs could be stored efficiently elsewhere and versioned. It's great that Perforce works and I've heard others in the graphics field using it, so it satisfies a need. Don't know if/when it would be a general need for say GitHub users.
firesteelrain 3y ago
That’s why you need a binary repository like Artifactory and not store your large files in Git. But you can still track them in Git with the large files in a binary repository like Artifactory.
withinboredom 3y ago
This is a solved problem with git. I’ve worked on bigger projects than yours with histories that are so big you can’t clone them if you wanted to. I’ll make a note to drop what to google for tomorrow, but basically the history is fully available but git knows how to query it over the network. When you open a file, it loads it over the network. Remote build systems do your builds. Most of this was built by Microsoft to work on Windows with git. We moved from SVN in the late 2010’s, and holy crap man, did it change our workflows. No longer were we passing around patch files in a team for code reviews, but actually reviewing code somewhat like on GitHub. It was magical.

agumonkey 3y ago

That's what i liked about git too. It felt like a powerful, ready to use tool. CVS and SVN were more bureaucratic, slower and limited. Took zero second for me to drop everything else. The underlying model is alien to many, it requires non black box approach to get out of pits sometimes but to me it's always worth knowing. The only decision I dislike about git is the soldered staging area idea. There's a reason why most people end up stashing 109 times a day, and I think there's a golden idea in merging the two

cflewis 3y ago

This post is a terrible failure of imagination that would make one stop language development as C because it was so much better than Assembly. If you have no problems with Git, then I’m happy for you. I certainly have problems with Git, eg its inability to handle large repositories meaningfully (enjoy a Chromium checkout!), the arcane CLI commands, the shut-your-eyes-and-hope of moving commits between branches and other sharp edges. That Git has been as resilient as it has is largely a function of being written by Torvalds and GitHub network effects. It isn’t for lack of better/as good features found in other VCS methodologies.

penguin_booze 3y ago
> its inability to handle large repositories meaningfully Out of curiousity, what other SCM tools can pull this off better?
- cflewis 3y ago
  I haven’t played with many because I simply don’t have the time between work (Google’s Piper and Git) and kids. Piper handles the monorepo by only offering files when requested by the file system at the specified commit (this is probably a gross or even incorrect simplification, but is how it presents to the user). There are good reasons that one should keep the whole commit history to distribute a source of truth, but at the same time if one is going to place full trust in something like GitHub (as many do), there’s no reason that full trust can’t be given to a similar website that provides a Piper model with some mechanism to request more than one commit to be brought to local storage (to get more sources of truth). End of the day, a large repo checkout is going to be limited by either your network, your CPU/storage to perform archive expansions, or frequently both. I get the impression that Android and Chromium are expanding faster than those other things are improving, but have no data to back that up.
- slalomskiing 3y ago
  Almost every big game studio uses Perforce
sroussey 3y ago

nunez 3y ago

Wholeheartedly agree. Going from SVN to Mercurial was a night and day experience. Going from Mercurial to Git was a marginal improvement initially but a lasting change long-term. Then there are the "visual" VCSes like Rational and TFS that are designed to _only_ work within an IDE and grokking them involves wading through hundreds of pages of corporate tech docs. VCSes (or at least the ones I used) were generally awful before Git.

em-bee 3y ago

i mostly agree that git can do almost anything (but see the limitations others bring up), however this claim is easy to disprove: Whatever effort you are putting into seeking or building an alternative, instead put that effort towards becoming a Git expert. building an alternative naturally is more work than to learn git for one person, but not everyone needs to do that. a few people building an alternative could save the learning effort of many more people. instead i'd like to point out a different reason why rebuilding git may not solve the problem: git is good because it is powerful and flexible. that power and flexibility by necessity makes git more complex and difficult to use. you can build a simpler system, but then half of todays git users won't be able to use it because it won't have the features they need. and a system that has all the features of git today and also solves the problems it currently has will be even more complex and less straigt forward to use. the best approach is probably to have a common backend that has all the power and flexibility needed, and multiple different frontends that are simplified to only expose the features needed for a particular workflow.

mlsu 3y ago

All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Git solves the deeply complex problem of distributed version control. Most complaints about git are actually complaints about the essential complexity of the problem, not the accidental complexity of the tool used to solve it.

jltsiren 3y ago
Most complaints about git are about the design philosophy of the tool. While there are complex edge cases in distributed version control, the vast majority of situations people actually encounter are not that complex. But because git prioritizes the worst case over the typical case, it's much less usable than it could be.
baazaa 3y ago
Totally agree that people spend way too much time complaining about git's solutions but there's not nearly enough criticism of the fact it's solving the wrong problem 99% of the time. I want to share 5k LOC with a colleague. Anyone who thinks that requires a decentralised solution in 2023 is unwell. I recently wasted a few hours because I forgot to fetch before running some code. Sure the UI could be better (if you're very tired and you're told you're up-to-date you'll stupidly believe it), but fundamentally the 'feature' that caused this problem is something I'll never use. I'm always going to code with a connection to the internet. I shouldn't need to mentally keep track of local vs remote because that distinction simply shouldn't exist.
- yencabulator 3y ago
  What you fail to understand is that, outside of all talk about decentralization, keeping local state is a huge performance optimization. Tagging a large CVS tree used to take several minutes, because it would talk to the remote server separately about every file. History browsing & bisect are very pleasant in Git because the local computer already has all the information, and just needs to present it to you.

Affric 3y ago

Great comment. Git really needs a good git tutor game. Like vim tutor or any one of the n*x/shell games.

deleted 3y ago

[deleted]

grecy 3y ago

> I’m old enough to have used RCS, CVS, SVN, then finally Git I'm old enough to have used CVS, SVN and then a bit of git. I remember the big selling point to go from CVS to SNV was "you can put binaries in there!" ... which we never did. And now I see the selling point to go from SNV to Git is "you can do really complicated stuff like rebase".... which we've never done. For a team who just does run of the mill distributed version control stuff (commits, diffs, blame, conflict resolution), can you explain why git is such a huge benefit over SVN?

gitaarik 3y ago
SVN doesn't do very good conflict resolution. It especially becomes more of a problem when you have multiple people working on several branches, that might want to merge some of each other's work. Apart from this, git also came with many more advanced features that improves branch and history management.

darose 3y ago

> Git has no such problem. There’s nothing it can’t do. It can't display me the branch I'm working on, starting from the commit that began the branch, until the last commit. (Or if it can, I have no idea how to do it.) This isn't a functionality issue, but rather a conceptual one. Git just fundamentally thinks of branches differently than I do. (And, maybe most humans?) To me, a branch begins ... when I branch it. To git, a branch begins ... at the very first commit ever in the repo, since they consider commits that were made before the branch point to still be part of the branch. The branch point then is just another commit to git - and not even one that they think is important enough to highlight. But without any ability to clearly identify the branch point, you can often find yourself looking through a forest of commits that are irrelevant to what you're really searching for. I spent the better part of an hour the other day trying to figure out how to identify my branch point. (For the record, the best solution I eventually found was: cat .git/refs/heads/<branch name>.) Just my $0.02, of course, but IMO this is absurd - and a big feature gap / user friendliness issue with git compared to other VCS's. IMO git is just another step in the evolution of VCS's, and not necessarily even one of the better ones. Its concepts, functionality, and feature set are focused primarily on distributed development and multiple people maintaining different source trees ... which is fine for the Linux kernel and other projects that heavily use that use case. But many/most projects don't work that way, and for them a centralized VCS is sufficient. I have no doubt that a better VCS will come along and replace git one day.

kmacleod 3y ago
git log <base-branch>..<branch> I often need the count of commits, usually for build IDs, git rev-list --count <branch> ^<base-branch> I usually use gitk for visualizing branch commits. CLI equivalent is git log --graph --oneline --all
- liveoneggs 3y ago
  he is saying that finding <base-branch> is too hard. There is probably some magic with git merge-base or git show-branch but I don't know them well enough to do it