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

91–100 of 559 posts

Re: Is Git Irreplaceable? (2019)

#91

Post by roca »

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 was a better one. I don't think there is.

Re: Is Git Irreplaceable? (2019)

#92

Post by deanCommie »

aylons wrote: post #83
romwell wrote: post #58

When people talk about killer features missing in Git, there is more beyond the UX and mono/poly repo. One thing is code review. There is no code review in Git. What I expect in 2020 is that I should be able to specify reviewers for the commit (which I pick out of a list of people who can approve it). These people should be able to leave comments on the commit. I should be able to both respond to comments and modify…

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 specific hunk of code changes (comments), or the discussion over those changes in a specific version?

Environments and development practices may change, but the code review that led to a particular code decision at some point in history are a valid representation of the context at that time in history.

Don't get me wrong, I'm not lacking these features in Git, and am happy to get them from other platforms like Github, but I think the comment you're responding to is astute that one can imagine a git replacement that incorporates code review functionality as a first-tier feature.

Re: Is Git Irreplaceable? (2019)

#93

Post by randallsquared »

nwallin wrote: post #84
ken wrote: post #19

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

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…

It would have to be specific to certain languages, which would, in turn, hinder adoption of new languages to some degree if the git-next took off. So, I'd prefer not to have that be a feature. :)

Re: Is Git Irreplaceable? (2019)

#94

Post by phodge »

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.

> Because of git's shortcomings polyrepo is a near necessity

I'm intrigued by this claim. I've come to the opposite conclusion - that monorepo is near necessity with git because there's no tools for branching/rebasing multiple repos at once.

Re: Is Git Irreplaceable? (2019)

#95

Post by jayd16 »

m463 wrote: post #15
enjo wrote: post #7

Earlier quoted context omitted.

Perforce is still in use in content heavy industries because Git still struggles with large binaries. Something with git branch semantics that could handle those files would be huge.

I actually like perforce. (if you're not constrained by distributed) It does huge well, and I like the one-number changelist.

I really miss being able to check in chunks instead of full files, and streams are a poor replacement for git branches but it does let you do monorepo. P4V is a buggy mess though.

Re: Is Git Irreplaceable? (2019)

#97

Post by smt88 »

hn_acc_1 wrote: post #38
ken wrote: post #19

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

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

Git is extremely user-unfriendly from the command line.

It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space.

Re: Is Git Irreplaceable? (2019)

#98

Post by frutiger »

nwallin wrote: post #84
ken wrote: post #19

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

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.

Re: Is Git Irreplaceable? (2019)

#99

Post by donw »

romwell wrote: post #58

When people talk about killer features missing in Git, there is more beyond the UX and mono/poly repo. One thing is code review. There is no code review in Git. What I expect in 2020 is that I should be able to specify reviewers for the commit (which I pick out of a list of people who can approve it). These people should be able to leave comments on the commit. I should be able to both respond to comments and modify…

> And yes, there are external tools for code review. But that all should be a part of version control.

There are many different code-review workflows, and for teams that do full-time pair-programming, code review happens in real-time as the code is written.

Trying to bake support for all of that into something that is also a good VCS sounds like a recipe for one of those clock-birdfeeder-machete-flashlight-massager tools that you used to see on the back pages of outdoor magazines in the 90s.

Re: Is Git Irreplaceable? (2019)

#100

Post by bb88 »

phodge wrote: post #94
jayd16 wrote: post #89

Earlier quoted context omitted.

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

> Because of git's shortcomings polyrepo is a near necessity I'm intrigued by this claim. I've come to the opposite conclusion - that monorepo is near necessity with git because there's no tools for branching/rebasing multiple repos at once.

I think he's talking about large files there, which is an issue in GIT btw.

I would use it for storing and syncing libraries of large images for my photography, if it were feasible.

Post reply on HN