Is Git Irreplaceable? (2019) • Hacker News Board

Re: Is Git Irreplaceable? (2019)

#111

Post by harry8 » Tue, Jan 07, 2020, 5:28 AM UTC

Taking the question literally, obviously not. If git became a problem due to some unforseen licensing issue or whatever mercurial does the job just fine right now and has for years.

As a heads up if you're stuck on cvs, svn or other stupid vcs due to "old-codgers" in your office, mercurial has a shallower learing curve and easier ui to get the same job done which may make it easier to switch.

Either git or mercurial, who cares? Either of them until there's something better. Never deal with SVN & CVS branches and merges again. Feel the immediate team productivity boost which will pay for the initial learning curve costs by day 2. Seriously.

Re: Is Git Irreplaceable? (2019)

#112

Post by lmm » Tue, Jan 07, 2020, 5:31 AM UTC

rhabarba wrote: post #26

l0b0 wrote: post #22

It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the…

> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.

Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).

Re: Is Git Irreplaceable? (2019)

#113

Post by HALtheWise » Tue, Jan 07, 2020, 5:34 AM UTC

roca wrote: post #91

rurp wrote: post #44

I 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…

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.

Re: Is Git Irreplaceable? (2019)

#114

Post by james_s_tayler » Tue, Jan 07, 2020, 5:41 AM UTC

dilap wrote: post #102

hn_acc_1 wrote: post #38

Earlier quoted context omitted.

I don't see any obvious flaws with Git. The monorepo/polyrepo discussion exists apart from your choice of version control system and has little to do with Git, as far as I can tell

cherry picking is a shitshow! i would love to be able to use a patch-based VC.

You can still generate and apply patches with Git.

Re: Is Git Irreplaceable? (2019)

#115

Post by braindeath » Tue, Jan 07, 2020, 5:42 AM UTC

colechristensen wrote: post #65

foota wrote: post #32

Earlier quoted context omitted.

Doesn't git fall apart for long wide checkouts and large files?

Git doesn't work very well when trying to version control things which aren't text and are large binary files. There's an acceptable workaround which is only a little awkward with git-lfs. The general consensus is that putting big files in git means you're doing something wrong and the problem is with your environment not git. (or there are special-purpose tools for your kind of workflow which handle the specifics of…

> The general consensus is that putting big files in git means you're doing something wrong and the problem is with your environment not git.

This is not a “general” consensus. It’s a consensus among hardcore proponents of git. I love git, it has made my life better. I still think it’s large file support story is shitty/suboptimal, and there are valid use cases where a general purpose VCS is used to track large binary assets along code and git would do well to be a general purpose VCS. It’s a limitation of git. It’s not a fatal limitation, and git still has enough benefits (which include availability and mindshare), but it is still an unfortunate limitation and somewhat ironic for a tool born in a world where everything is just a “sequence of bytes”.

Re: Is Git Irreplaceable? (2019)

#116

Post by HALtheWise » Tue, Jan 07, 2020, 5:42 AM UTC

One major fundamental issue with git that nobody has brought up is that its data model is close-to-incompatible with some of the current legal and moral requirements around data privacy today. For example, as far as I can tell, GDPR allows any European citizen who has ever committed to the Linux kernel to request that their name be permanently expunged from their contributions, and everyone with a git clone of the kernel is legally obligated to perform a rebase to do so. It's possible to make a DVCS where that is an easy operation, but git very much isn't it. That means it can't be used to store personal data, and even standard corporate policies of "we delete old historical records so they don't bite us in court" aren't supported.

There are definitely times you want to store the full history forever, but it would be nice to have a DVCS that gave other options.

Re: Is Git Irreplaceable? (2019)

#117

Post by james_s_tayler » Tue, Jan 07, 2020, 5:43 AM UTC

rhabarba wrote: post #54

hn_acc_1 wrote: post #38

Earlier quoted context omitted.

I don't see any obvious flaws with Git. The monorepo/polyrepo discussion exists apart from your choice of version control system and has little to do with Git, as far as I can tell

> I don't see any obvious flaws with Git. Merge conflicts.

No VCS will be merge conflict-less without locking files.

I'd rather not lock files.

Re: Is Git Irreplaceable? (2019)

#118

Post by hamandcheese » Tue, Jan 07, 2020, 5:46 AM UTC

james_s_tayler wrote: post #106

comex wrote: post #48

Git'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'd say the number of git repos on Earth that would encounter problems of that nature would be a vanishingly microscopic minority. Sure, it's a problem for those companies but it's not a problem for anyone else.

Vanishingly small in number, but quite significant in terms of the number of developers working in them.

Re: Is Git Irreplaceable? (2019)

#119

Post by chx » Tue, Jan 07, 2020, 5:47 AM UTC

DecoPerson wrote: post #40

> 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…

> These replacements were seemless to users.

Not at all. I remember how long it took for Cat 5 to replace thinnet.

Re: Is Git Irreplaceable? (2019)

#120

Post by kemitche » Tue, Jan 07, 2020, 5:47 AM UTC

comex wrote: post #48

Git'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 I can feel confident that Git will have the power to do whatever it is I'm trying to do. A competitor would need to do what git does as well as git does it, with a UX that is not just marginally better but categorically better, to unseat git. (Marginally better isn't strong enough to overcome incumbent use cases)

And for the record: I think git-lfs issues are primarily usability issues, and tech improvements. The tech enhancements will be solved if there's enough desire, and as I mentioned the usability problems are more annoyances than actual problems.