Is Git Irreplaceable? (2019) • Hacker News Board

Re: Is Git Irreplaceable? (2019)

#251

Post by squiggleblaz » Tue, Jan 07, 2020, 10:04 AM UTC

randallsquared wrote: post #93

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…

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

I think you could write it as the ability to a diff on a binary ast without fussing too much about what the ast represents. Then you merely need to write a parser/serialiser combo for your language to the ast as a repo plugin.

Otherwise it won't just be new languages which suffer, but users of supported languages will suffer when there's an upgrade.

Re: Is Git Irreplaceable? (2019)

#252

Post by javajosh » Tue, Jan 07, 2020, 10:05 AM UTC

yodsanklai wrote: post #234

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.

I hope it's the last DVCS, if it can save me the hassle of learning a new one. There is some learning curve, but it works just fine once you know how to use it.

Over time you realize there are no transient states. You cannot neglect, for example, complex install just because it "happens once". Nothing ever happens just once. You will always have to reinstall, probably multiple times. So when people say the same thing about installation complexity, they are being naive.

In the same way, learning is not a transient state either. You will always have to relearn. Those impossible barriers that you eventually got through will reduce to speedbumps - but they will always be there, slowing you down. And if you don't use it enough, you'll have to relearn.

Also, be aware that once you've climbed a learning curve, at least unconsciously you are no longer incentivized to simplify it for those who come after. Why reduce the barrier-to-entry for others, after all? You got through it, so why can't they? And this is why generations of kids learn bad music theory, and generations of physicists learn bad particle names. It's important to be aware of this effect so you can counter-act it.

Re: Is Git Irreplaceable? (2019)

#253

Post by adrianN » Tue, Jan 07, 2020, 10:07 AM UTC

neerajsi wrote: post #209

rumanator wrote: post #198

Earlier quoted context omitted.

The problem boils down to refactoring a large monolith. I feel like Git is a scapegoat for a much larger problem.

Let's say you started with a well factored set of code that is managed within your organization. What advantage is there to having multiple repos if you're not limited by your tools? Refactoring is easier within a single repo...

In my experience, code doesn't stay well factored unless there are technical hurdles that keep it so. That of course doesn't have to be a repo boundary, but in can be.

Re: Is Git Irreplaceable? (2019)

#254

Post by roca » Tue, Jan 07, 2020, 10:07 AM UTC

mrunkel wrote: post #189

james_s_tayler wrote: post #137

Earlier quoted context omitted.

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.

That's right. The Git CLI is the default Git UI.

A better Git UI is possible, like Gitless. A GUI that just has the functionality of the Git CLI doesn't solve the problems I care about, like the staging area being unnecessary and complex.

Re: Is Git Irreplaceable? (2019)

#255

Post by alkonaut » Tue, Jan 07, 2020, 10:09 AM UTC

dragonwriter wrote: post #236

alkonaut wrote: post #228

Earlier quoted context omitted.

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, bran…

> I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. That's what UIs (whether CLIs or otherwise) for standardized workflows like git-flow are, IMO.

It doesn't nearly go all the way there though. Why do people need to use a command line and a gui tool (usually) for git? Because it's fundamentally not written to be used with a GUI. That I think is one of its biggest flaws. Using a GUI with git always feels like you are missing vital information and just trying to poke a cli underneath to do what you want.

Some design decisions also shine through like "no branch is more important than any other branch" which is completely mental considering how people actually use git.

Re: Is Git Irreplaceable? (2019)

#256

Post by int_19h » Tue, Jan 07, 2020, 10:09 AM UTC

mikl wrote: post #229

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…

Git scales well enough for almost everyone (especially if you have a little discipline with what you put in the repo). It’s only huge megacorps that need larger scale things like GVFS. As for large files, that is not what Git is for. Git is for source code . Much like how you don’t put large files in your RDBMS, you should not be putting them in your SCM either.

What if you need to version them? Git imposes a very specific versioning model: version is a property of the entire repository. Thus, not including some file in the repo implies that it's not versioned in the same manner. It's not just a function of binary vs source.

Re: Is Git Irreplaceable? (2019)

#257

Post by grive » Tue, Jan 07, 2020, 10:10 AM UTC

donw wrote: post #99

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

e.g. -- fossil.

This is exactly the issue with it: its author(s) lament that git has not all of these things integrated, but they are ignoring that this is exactly why fossil cannot gain a wider adoption.

It has opinions about how the team and the project should be run / managed / documented. This is not for the tool dev to have these opinions

Re: Is Git Irreplaceable? (2019)

#258

Post by int_19h » Tue, Jan 07, 2020, 10:13 AM UTC

jamil7 wrote: post #221

rhabarba wrote: post #54

Earlier quoted context omitted.

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

I've worked in teams where developers seemed terrified of merge conflicts, to the point of telling eachother not to edit a particular file which seems absurd. Maybe I don't know any better but they seem like part of life.

When at least one person is making changes that touch large parts of the file, it's very sensible to ask others to not touch it, if you don't want to spend hours merging it manually later.

Re: Is Git Irreplaceable? (2019)

#259

Post by rimliu » Tue, Jan 07, 2020, 10:14 AM UTC

matsemann wrote: post #216

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.

People have probably been happy with their tools for centuries. Just because one cannot imagine something better doesn't mean there's no possibility for it to exist. If anything, this defeatist attitude may prove the author right.

I remember what was the go-to tool before git. It was Subversion. And CVS before that. I would not say people were happy with those tools.

Re: Is Git Irreplaceable? (2019)

#260

Post by int_19h » Tue, Jan 07, 2020, 10:15 AM UTC

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

FWIW, in case of Microsoft at least, it's more a question of product size than company size. Microsoft doesn't use a single monorepo for everything, like Google (so far as I know) does - just look at http://github.com/microsoft/; and that's not even counting all the VSO repos! It uses product-specific monorepos for some large products.