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

151–160 of 559 posts

Re: Is Git Irreplaceable? (2019)

#151

Post by frutiger »

hinkley wrote: post #145
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.

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?

Re: Is Git Irreplaceable? (2019)

#152

Post by kccqzy »

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.

Re: Is Git Irreplaceable? (2019)

#153

Post by glandium »

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…

- Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism.

https://github.com/git/git/blob/master/Documentation/technic...

Re: Is Git Irreplaceable? (2019)

#154

Post by frutiger »

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…

> That's like saying DVCS has nothing to do with VCS

I could see myself agreeing to that.

Re: Is Git Irreplaceable? (2019)

#155

Post by Jasper_ »

yjftsjthsd-h wrote: post #128
deanCommie wrote: post #92

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

Perhaps commits should support key:value metadata? (I was about to say "tags", but that means something different here) That would let you support "reviewer:person@foo.bar" or whatever you want, without baking workflow assumptions into the VCS.

Sounds like you want git notes

https://git-scm.com/docs/git-notes

Re: Is Git Irreplaceable? (2019)

#156

Post by MaulingMonkey »

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…

> 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 constantly run into git scalability issues as an individual. I don't use any of the UI clients because they all fail hard on mostly-code git repositories. I abandoned my VisualRust port in part because the mere 100MB of mingw binaries involved for that meant it was using github LFS, which meant CI was hitting github quota limits, and as I wasn't part of the organization - nevermind an admin with billing rights - I couldn't even pay to up said quota limits paying out of pocket myself even if I wanted to.

I'm not going to inflict git's command line experience - which confounds and confuses even seasoned programmers - on any of the less technical artists that might be employed at a typical gamedev shop, even if git might be able to scale acceptably if locally self-hosted at a single-digit employee shop.

A few dozen or hundred employees? Forget it. Use perforce, even though it costs $$$, is far from perfect, and also has plenty of scaling issues eventually.

Re: Is Git Irreplaceable? (2019)

#157

Post by hinkley »

pbh101 wrote: post #125
tick_tock_tick wrote: post #70

Earlier quoted context omitted.

I think it doesn't exist because there is no demand for that to be part of the codes history. Nothing you've described sounds very useful after a month or so.

All this talk of Git-sympathetic code review tools and nobody has mentioned Gerrit, which seems at least somewhat close to what is being described. Each patchset of each review is its own Git ref and is often referenced in the final commit. Separately, I know many including myself who would love for code review comments to more seamlessly be integrated into the code browsing experience.

People also seem to be conflating review comments associated with lines of code with an opinionated code review tool.

You can keep the banter with the code and the go-no-go decision separate, even external. But post mootems have worked better when someone realized that one of the team repeatedly calls out a class of errors that bite us later and they’re being ignored. You have the ability to prevent this error. Wise up or that person will decide rightfully that we are a bunch of clowns and leave.

Re: Is Git Irreplaceable? (2019)

#158

Post by Ace17 »

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

Re: Is Git Irreplaceable? (2019)

#159

Post by shakna »

HALtheWise wrote: post #110
thenewnewguy wrote: post #81

Earlier quoted context omitted.

Merge conflicts are a part of any VCS that allows two people to edit the same file at the same time.

However, in some cases (like non-mergeable binary files), it is actually better to have a system that allows one user to take a lock on a file and have exclusive editing abilities. The git protocol has no support for those workflows, and so people end up using a Google Doc or something to track who is modifying what file. Definately a place for improvement.

How do you lock a file in a distributed system? Many people won't be online. Many people won't be on the exact same head.

Re: Is Git Irreplaceable? (2019)

#160

Post by shakna »

_ZeD_ wrote: post #133
jerf wrote: post #60

Earlier quoted context omitted.

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)

Git still let's you check out particular directories at particular commits. It's just a specialised usecase rather than the default.

    git --work-tree=/path/to/outputdir checkout HEAD -- subdirname
Post reply on HN