Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

Post reply on HN
Print view View original

181–190 of 559 posts

Re: Is Git Irreplaceable? (2019)

#181

Post by chme »

kemitche wrote: post #120
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 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).

I would say that the sole thing git was developed for, the Linux Kernel, is (starting to be) painful to work with when using git.

Re: Is Git Irreplaceable? (2019)

#182

Post by gatekeeperthrow »

chubbyrabbit wrote: post #55
dickjocke wrote: post #37

Earlier quoted context omitted.

Can you explain more about that? I've worked with both and I feel like monorepo is kinda a pain, but I dont understand where Git fits in to either directly. Seems like it just snapshots files.

It's only a problem at a really large scale. At the scale of Microsoft or Facebook, there are factors that lead to the use of a monorepo being more efficient. At that big of a scale, companies have enough resource to develop internal tooling to deal with the problem (e.g. the use of Mercurial at Facebook).

It would be nice if you and everyone else stopped gatekeeping this problem.

We have 600 devs and face these problems. I can assure you we sure as hell dont have the resources spare to reroll git. We're way too busy rerolling everything else.

Re: Is Git Irreplaceable? (2019)

#183

Post by hinkley »

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…

Bob Martin claims at various points in time that half of all developers have less than five years experience, and attrition and expansion of CS degrees has maintained this.

Five years after introducing a replacement you could have half a team that never used it at all, just like SVN is now.

Re: Is Git Irreplaceable? (2019)

#184

Post by hinkley »

frutiger wrote: post #151
hinkley wrote: post #145

Earlier quoted context omitted.

Except you have to run them every time. Imagine instead of that were available as a sort of materialized view.

> Imagine instead of that were available as a sort of materialized view. I don’t understand what you mean by this, can you provide some more detail?

Why do we have byte code? Why not run everything in interpreters? Because parsing pure text takes a lot of work. So we store it in an intermediate mode to economize.

Saying just parse it every time is denying that there are very real costs associated with hat decision.

Re: Is Git Irreplaceable? (2019)

#185

Post by Falkon1313 »

rumanator wrote: post #143
ken wrote: post #29

Earlier quoted context omitted.

But did you think that RCS, CVS, or SVN were also good enough? Or is this new?

> But did you think that RCS, CVS, or SVN were also good enough? SVN required a centralized server and didn't even supported branching, so no.

Not sure what variant of SVN you were using that didn't support branching, everyone I knew used branches.

It did have problems with occasional inexplicable tree conflicts, which I do not miss. But that's the same as the pain of trying to rebase in git when things have diverged and it just starts spewing repeated conflicts for each and every commit. In either case, the easiest thing to do is make a fresh branch, patch your changes over, and go from there vs. trying to reintegrate the broken branch.

Re: Is Git Irreplaceable? (2019)

#186

Post by reissbaker »

kccqzy wrote: post #152
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…

Mercurial is probably that competitor. Only slightly slower than Git. Works on very large monorepos (as large as Facebook's or Google's monorepo). Very similar workflow as compared to Git, with some minor differences in terminology.

As an FB employee, I use hg regularly (because it is required). I would not use it as a git replacement for non-FB-sized repos. It has some weird design choices (e.g. branching is bad), and it very often requires manual intervention for merges that git performs correctly and automatically.

You can get around branching-is-bad by changing your workflows a bit, but you can't get around the bad merges: over time it's like death by a thousand papercuts.

Re: Is Git Irreplaceable? (2019)

#187

Post by taftster »

chme wrote: post #181
kemitche wrote: post #120

Earlier quoted context omitted.

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 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). I would say that the sole thing git was developed for, the Linux Kernel, is (starting to be) painful to work with when using git.

The Linux Kernel is big, but it's not likely as big (in terms of lines of code or pick your metric) as Google or Microsoft repositories. Maybe the kernel is just starting to feel that pain?

Honestly asking.. Do you speak from some level of authority that the Linux kernel is stretching the boundaries of git? Or are you just saying that more speculatively? What is the painful part?

Re: Is Git Irreplaceable? (2019)

#188

Post by taftster »

Ace17 wrote: post #158
kemitche wrote: post #120

Earlier quoted context omitted.

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 work for a 40-people game studio. A major limitation of git is how it deals with many "big" (~10Mb) binary files (3D models, textures, sounds, etc.). We ended up developing our own layer over git, and we're very happy ; even git-lfs can't provide similar benefits. This technique seems to be commonplace for game studios (e.g Naughty Dog, Bungee), so certainly git has room for improvement here.

Do you have tools that you can utilize diffs from your binary file changes? Or does a change simply just replace all the bytes.

I'd argue if it's the later, that git was never the right choice to begin with. You don't really want to record a full 10MB of data every time you change one pixel in your texture or one blip in your sound, right?

So I don't know if this is a "major limitation" of git per se. Not saying there's a better solution off-the-shelf (you're obviously happy with your home grown). But this was probably never a realistic use for git in the first place.

Re: Is Git Irreplaceable? (2019)

#189

Post by mrunkel »

james_s_tayler wrote: post #137
roca wrote: post #91

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

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.

The manner in which it takes instructions and returns results is the User Interface.

That's what the person you are responding to is talking about.

UI = User Interface which is the interface between the User and the Program GUI = Graphical User Interface. Same thing, but pretty.

Re: Is Git Irreplaceable? (2019)

#190

Post by hvidgaard »

reissbaker wrote: post #186
kccqzy wrote: post #152

Earlier quoted context omitted.

Mercurial is probably that competitor. Only slightly slower than Git. Works on very large monorepos (as large as Facebook's or Google's monorepo). Very similar workflow as compared to Git, with some minor differences in terminology.

As an FB employee, I use hg regularly (because it is required). I would not use it as a git replacement for non-FB-sized repos. It has some weird design choices (e.g. branching is bad), and it very often requires manual intervention for merges that git performs correctly and automatically. You can get around branching-is-bad by changing your workflows a bit, but you can't get around the bad merges: over time it's lik…

What kind of merges does git handle that hg doesn't? If it's just a matter of figuring what goes where, someone that uses hg daily could copy the implementation from hg. It could be a big organization that uses daily for instance.
Post reply on HN