git has big problem with binary files, hopefully a new technology can fix that
Is Git Irreplaceable? (2019)
131–140 of 559 posts
Re: Is Git Irreplaceable? (2019)
#132> 1. Metcalfe's original Ethernet has been replaced a bunch of times... These replacements were seemless to users. New Ethernet adapters were compatible with at least the previous spec. The Git import/export of Fossil is not seemless at all. It actually adds quite a bit of complexity if you want to introduce it your regular workflow. > 2. Microsoft's long-term stalwarts Windows and Office are dying... Citation needed…
Wifi mostly replaced ethernet for user facing applications.
There was partial protocol compatibility between ethernet and wifi, but the user experience was very different. Some features were lost or degraded (eg speed, reliability, security, configuration complexity) but a pain point (cables) was fixed.
Re: Is Git Irreplaceable? (2019)
#133Earlier quoted context omitted.
But did you think that RCS, CVS, or SVN were also good enough? Or is this new?
Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all…
>>> [SVN] made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories.
that is a feature! You don't know how I miss that!
(that, and the handling of blobs)
Re: Is Git Irreplaceable? (2019)
#134Earlier quoted context omitted.
If I were to pie in the sky dream up a replacement for git, I'd have it store the AST of the parsed code instead of a text file. It would solve a lot of problems with refactoring crapping all over the history. Like I said, pie in the sky. Probably never gonna happen. Personally I don't see git's problems with large binary files and tens of millions of commits as being major issues. Those two alone are way less valuab…
What you want has nothing to do with git (which is a storage model). You can use arbitrary diff and merge resolution algorithms with git's plumbing, which would give you the AST-aware functionality that you want.
That's like saying DVCS has nothing to do with VCS -- it's just the server model. Every major advance has been accomplished by increasing the scope of version control.
Arbitrary diff/merge in Git is a great example of the Turing Tar-Pit. It's possible, but prohibitively inefficient for many things I want to do. You can't add your own types, index, or query optimizations.
Today, if I want to store data for my application, I have a choice between good support for rich object types and connections (e.g., Postgres), or good support for history and merging (e.g., Git). There's no one system that provides both.
Re: Is Git Irreplaceable? (2019)
#135Earlier quoted context omitted.
Vanishingly small in number, but quite significant in terms of the number of developers working in them.
All of the organizations that have outgrown git will have such incredibly specific requirements meaning nothing but a custom built tool will work for them.
The so called problem would also vanish if the monorepo was modularized and broken up into smaller repos.
Re: Is Git Irreplaceable? (2019)
#136I really doubt Git is going anywhere for the foreseeable future, but I could imagine a more approachable VCS catching on. Git is extremely opaque to most new developers and even for experienced devs looking up a new command. Sometimes I look up how to perform an unfamiliar task with Git and find 4-5 competing answers on Stackoverflow with no real clear explanation of why one is better than another. If an easier VCS c…
Git's UI is unbelievably bad. However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS: almost its entire target market has already paid the cost of learning git. That problem could be gotten around if there was some enormous pool of potential VCS users who aren't using VCS currently but would if there…
However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS
I think this is true if you think the target market for VCSs is professional software developers only. But there are other people writing code that might care less about the fact that Git is the standard for professional software development and don't want to pay the cost of learning or using Git: data scientists, scientists in general, new media artists, most high school students, etc. I've had a hard time selling Gitless (https://gitless.com) to undergrad CS students, but it is easy to sell to non-CS students that write code.
That said, GitHub is a big thing so any new VCS probably needs some story for Git-compatibility. Even tools that have built-in version control like Overleaf have some way of synchronizing with Git repos.
Re: Is Git Irreplaceable? (2019)
#137I really doubt Git is going anywhere for the foreseeable future, but I could imagine a more approachable VCS catching on. Git is extremely opaque to most new developers and even for experienced devs looking up a new command. Sometimes I look up how to perform an unfamiliar task with Git and find 4-5 competing answers on Stackoverflow with no real clear explanation of why one is better than another. If an easier VCS c…
Git's UI is unbelievably bad. However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS: almost its entire target market has already paid the cost of learning git. That problem could be gotten around if there was some enormous pool of potential VCS users who aren't using VCS currently but would if there…
It doesn't have a UI. Its just a program that takes instructions and does what you tell it. If you want a nice fancy GUI for Git there are plenty of reasonable options. Fork is the one my coworkers seem to be enamoured with at this point in time. I myself don't see the need to use any sort of GUI for Git the vast majority of the time.
Re: Is Git Irreplaceable? (2019)
#138Earlier quoted context omitted.
Git's UI is unbelievably bad. However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS: almost its entire target market has already paid the cost of learning git. That problem could be gotten around if there was some enormous pool of potential VCS users who aren't using VCS currently but would if there…
The obvious pool of people who don't currently use VCS's is everybody who mostly deals with files that aren't plain text. Using git to collaborate on Photoshop documents, Word docs, Jupyter notebooks, videos, or any other non-plain-text format is a frustrating nightmare, and a VCS solution that provided revision tracking and collaboration for all those filetypes would open up a new set of users.
Just use SharePoint.
Re: Is Git Irreplaceable? (2019)
#139Git's biggest flaw is that it doesn't scale. If a new system can fix that without sacrificing any of Git's benefits, I think it can topple Git. It's ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos. There have been some attempts to work around this. Google's `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it's a (very) le…
I disagree that Git's biggest flaw is its lack of scalability. Cases where git needs to scale tend to be isolated to companies that have the manpower to build a finely-tuned replacement (see: MS, Google). Git's flaws are primarily in usability/UX. But I think for its purpose, functionality is far more important than a perfect UX. I'm perfectly happy knowing I might have to Google how to do something in Git as long as…
Scaling isn't even just about number of files or size of them. A problem I've hit is just in having cross-repo stuff work well. Monorepos are helpful partly because git submodules are not ideal for good workflows, and splitting stuff across multiple git repos can backfire (it doesn't help that almost all the tooling around CI and the like is repo-based instead of project based).
I would love a layer over Git to handle workflow issues related to multi-repo projects
Re: Is Git Irreplaceable? (2019)
#140Earlier quoted context omitted.
I don't think this should be part of version control, simply because is too tied to the environment and development practices that may not be shared by the whole set of current and future developers of any given project. The version control should keep the code history, not the paperwork history. What I think you're looking for could, however, use git as a platform for that. That's what GitHub, GitLab and the likes d…
I think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit. If all we cared about was code history, a super pure "version control" system would have one trunk, no branches, and a sequentially increasing version number with no commit messages or author information. But if you can annotate an entire commit with a descriptive message, why not annotate a sp…
> I think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit.
I don't agree. The responsibility of a version control system is to manage the changes made to the source code. The paperwork that goes with it is an entirely different, and separate, responsibility, just like ticketing systems and keeping track of tasks, epics, sprints, etc.
> If all we cared about was code history, a super pure "version control" system would have one trunk, no branches, and a sequentially increasing version number with no commit messages or author information.
That doesn't make sense because you're ignoring the fact that branches are used to host versions that are being developed independently at a specific moment in time, and merges are used to finally join contributions when they are ready to be added to the main branch. If you look at single branches and ignore the work being developed in any other branch, the history is as linear as you expected it to be.
> But if you can annotate an entire commit with a descriptive message
But you can.