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

291–300 of 559 posts

Re: Is Git Irreplaceable? (2019)

#291

Post by scrollaway »

ken wrote: post #134
frutiger wrote: post #98

Earlier quoted context omitted.

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

frutiger is correct that the diff algorithm has nothing to do with git itself, in that git can accept pretty arbitrary diff algorithms in the first place for all the commands that take one.

Check out git-diff(1) and --diff-algorithm. --anchored is the one I find the neatest.

Re: Is Git Irreplaceable? (2019)

#292

Post by erikbye »

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.

Why did you not use Plastic SCM or Perforce?

Re: Is Git Irreplaceable? (2019)

#293

Post by qznc »

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 believe there will be no scalable open-source VCS because the incentives are not there. While the technical problem is interesting, I decided not to work on it because of this. http://beza1e1.tuxen.de/monorepo_vcs.html

Re: Is Git Irreplaceable? (2019)

#294

Post by baud147258 »

tasuki wrote: post #199

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

Re: Is Git Irreplaceable? (2019)

#295

Post by afiori »

kortilla wrote: post #218
brylie wrote: post #213

Earlier quoted context omitted.

The interface is arguably the most important part. I.e. it is a tool developed for humans to use, so would ideally have simple, consistent, and by extension intuitive ergonomics. Elegance of internal implementation is secondary.

The interface can be swapped out if the underlying storage is fine. There is nothing preventing you from writing a different front end where “checkout” doesn’t do all the things.

Yet no one is doing it.

Re: Is Git Irreplaceable? (2019)

#296

Post by baud147258 »

kortilla wrote: post #218
brylie wrote: post #213

Earlier quoted context omitted.

The interface is arguably the most important part. I.e. it is a tool developed for humans to use, so would ideally have simple, consistent, and by extension intuitive ergonomics. Elegance of internal implementation is secondary.

The interface can be swapped out if the underlying storage is fine. There is nothing preventing you from writing a different front end where “checkout” doesn’t do all the things.

> There is nothing preventing you from writing a different front end

Or you could just use a tool where the interface is fine out of the box

Re: Is Git Irreplaceable? (2019)

#297

Post by diegof79 »

frutiger wrote: post #98
nwallin wrote: post #84

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

I used VisualAge's Envy for 3 years while working in a Smalltalk project.

Envy does versioning of classes and methods, and you can programmatically access to the model.

It allowed us to build tools around the VCS. For example, we had tools to merge multiple feature branches and resolve conflicts automatically. We also used the same tools to produce migration scripts for our database (GemStone). That was 18yrs ago! and today sounds irreal.

You can build tools on top of git, but the versioning “unit” gets in the way. (e.g imagine the possibility to encode refactorings in your change history and reapply or rollback them).

I’m not trying to criticize git. I think it is the best file based DVCS. My point is that many dev tools that we use today are extremely rudimentary, because the lack of good abstractions. And I don’t think that git provides a good model to build those abstractions on top of it.

Re: Is Git Irreplaceable? (2019)

#298

Post by afiori »

int_19h wrote: post #261
rumanator wrote: post #140

Earlier quoted context omitted.

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

If you can annotate an entire commit with a message, why not allow annotating parts of a commit (file/span) with a message, and why not allow those messages to form threads? At which point you get code review that is logged entirely in the history of the repo. Which is a very useful feature, and a huge value proposition of GitHub over raw git - git blame gives you the commit, but GitHub will also gives you the pull r…

I agree that such feature would be valuable, but I also have a counterpoint to answer the 'why not'

A difference between a commit message and a code comment/thread is that a commit message is more authoritative.

Re: Is Git Irreplaceable? (2019)

#299

Post by icebraining »

MaulingMonkey wrote: post #246
pja wrote: post #208

Earlier quoted context omitted.

The fact that you had a problem with github quotas isn’t really a problem with git though, is it?

The whole reason git lfs exists is to workaround git scalability problems. Its raison d'etre is problems with git. That one of - if not the - most popular tool to solve said git scalability problems, also has scalability problems in practice, is both ironic - and absolutely a problem with the git ecosystem. To be pithy - "Even the workarounds don't work." "Technically", you might say, "that specific symptom with git…

Not waiting to provide you with free storage is not a "scalability problem". I can't spend company money on Perforce either, is that a Perforce problem?

Re: Is Git Irreplaceable? (2019)

#300

Post by Already__Taken »

jayd16 wrote: post #89
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. Large files and long histories hinder its total dominance in the game and art industries. Because of git's shortcomings polyrepo is a near necessity not simply a stylistic choice. LFS is a bolt on solution that could/should have better support.

> LFS is a bolt on solution that could/should have better support.

Like gitlabs own web ide that seems to ignore LFS rules.

Post reply on HN