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

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

171–180 of 430 posts

Re: What comes after Git

#171

Post by globular-toast »

nine_k wrote: post #12
stellalo wrote: post #4

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious

On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pij…

> - Git is slow on large repos, even on an SSD.

I think this is an example of induced demand[0]. One of git's main advantages compared to other options is its speed. Git was so fast it completely changed the way you could work. It went from reluctantly interacting with version control when you needed to check in work, to integrating it tightly into your workflow. But, like with many things, people always find a way to "use up" the resource and make it slow again.

[0] https://en.wikipedia.org/wiki/Induced_demand

Re: What comes after Git

#172

Post by midenginedcoupe »

maccard wrote: post #157
midenginedcoupe wrote: post #112

Earlier quoted context omitted.

Absolutely. I've seen teams evaluate multiple revision systems before starting projects and each one has decided on Mercurial based on its technical merits. I'll take it on trust that git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero. I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team st…

> I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same. The big advantage of git is github and co, not git itself. By switching and using mercurial you lose all of the advantages of github too.

Well that's a different argument.

The irony is I use git for all my projects, too, due to the network effect. It's vastly easier to go with the flow rather than swim against the tide. But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(

Re: What comes after Git

#173

Post by sirmarksalot »

knighthack wrote: post #154

The only major problem I see with Git is that it's just a pain if you're working in a gigantic monorepo. Outside of this, I think it's achieved it's ultimate form and tradeoffs for what it was originally intended to do - and the majority of projects fall under that category, meaning that while Git can be improved, but it doesn't need to 'change' architecturally or philosophically to accommodate other things. Separate…

The large file problem is a major issue in games, and basically means that developers who would much rather use Git, don't have the option of using Git because it would be crushed under the weight of all the art assets. So instead everyone's forced to use Perforce or Subversion, with all the workflow impediments that involves.

Re: What comes after Git

#174

Post by hardware2win »

parasti wrote: post #94
silisili wrote: post #66

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…

Git has a terrible UI from a learning point of view. You can't learn Git by using its commands. You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Because Git is really just a brilliantly simple data structure manipulated by dozens of ad-hoc commands.

Is there any other soft where ppl do seriously advise newbies to learn its internals?

Everywhere it'd bee seen as a flaw from ux standpoint, but git gets a "pass"

Imagine having to read excel's or windows code in order to use it consciously, lol.

Re: What comes after Git

#175

Post by anonymous_sorry »

pizza234 wrote: post #120
pdmccormick wrote: post #100

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…

The checkout command is severely overloaded; I'd hardly remember the functions if it wasn't for aliases. The reset operations are also very inconvenient, due to the mix of: different types of reset (soft/hard); overlapping with the checkout command; different states of the files. Pushing is also overloaded, due to handling both branches and tags (this is probably due to the fact that both have refs). There are strang…

I was learning git around the time `switch` and `restore` were introduced to tackle the problem of checkout being overloaded. I started using the new commands and it instantly made more sense and began to click. I very rarely use checkout at all.

Something to be aware of when training junior devs. Do them a favour and learn switch/restore first!

Re: What comes after Git

#176

Post by tehbeard »

pydry wrote: post #160
R0flcopt3r wrote: post #153

Earlier quoted context omitted.

For you to enjoy using this tool you had to change the model your brain use, and you call that good UX? And using aliases means that your git is now different from you co-workers git. And when teaching the new guys you throw all these aliases at them that they have no idea what is or how work?

Knowledge of git has become a sort of status signifier. It "makes you a developer". I think for this reason there's a lot less pushback on its bad UX than there would be for any other program. It would render knowledge of its arcane guts less...special. The juniors will be forced to deal. It makes me wonder though, if needlessly arcane knowledge is and always was a part of other apprentice relationships.

How do you improve the ux though?

I see a lot of complaints about it, and agree that for all the porcelain, you do have to become familiar with the plumbing to solve issues.

But noones shown me a good alternate ux story, just different porcelain/fittings. I still have to reach under the sink because said new porcelain didn't stop/avoid a case sensitivity clash, or it barfed on a merge and left the repo still to merge.

Re: What comes after Git

#177

Post by anonymous_sorry »

bryanrasmussen wrote: post #138
pizza234 wrote: post #120

Earlier quoted context omitted.

The checkout command is severely overloaded; I'd hardly remember the functions if it wasn't for aliases. The reset operations are also very inconvenient, due to the mix of: different types of reset (soft/hard); overlapping with the checkout command; different states of the files. Pushing is also overloaded, due to handling both branches and tags (this is probably due to the fact that both have refs). There are strang…

if instead of checkout you had a bunch of separate functions you think you would remember those? Someone could probably make an argument that commands should be overloaded even more - clone, pull, and checkout could be merged for most of their common operations - as an example. Note: I am not necessarily for this but I'm not necessarily against it either. agree --patch is weird.

> if instead of checkout you had a bunch of separate functions you think you would remember those?

It does (switch/restore) and I do.

Re: What comes after Git

#178

Post by t43562 »

Version control as a way of distributing and versioning the built code and also of rebuilding it minimally.

Goodbye to installers and package managers....and traditional build systems.

Re: What comes after Git

#179

Post by i_have_an_idea »

> Kubernetes (the operating system of the cloud)

The post just loses credibility after this statement. Yes, Kubernetes is important, but "operating system" is a clearly defined technical term. Using it arbitrary on something that is clearly not an OS to achieve some sort of an off-topic emphasis effect undermines the credibility of the content.

Re: What comes after Git

#180

Post by nextlevelwizard »

R0flcopt3r wrote: post #153
pdmccormick wrote: post #100

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…

For you to enjoy using this tool you had to change the model your brain use, and you call that good UX? And using aliases means that your git is now different from you co-workers git. And when teaching the new guys you throw all these aliases at them that they have no idea what is or how work?

>"to use a tool the way it was intended you had to adjust to use the tool as it was intended to be used"

I sure wouldn't call that a _bad_ UX. As with any tool you have to adjust to the tool or make your own unless by some miracle someone shares your particular idiosyncrasies.

>"modifying tool makes it different from your co-workers tool"

Yes, but that is a big plus instead of a minus. If your co-workers asks how to do something you can just give them the content of the alias. I also alias `git` as `g` in my terminal. Is that going to cause problems for my co-workers? No.

Unless you are training a complete-fresh-out-of-school-junior the "new guy" should already know how git works and in either case that sounds like homework for them more than anything else.

Post reply on HN