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

151–160 of 430 posts

Re: What comes after Git

#151

Post by ferruck »

vaughan wrote: post #74
kache_ wrote: post #7

Nothing. Keep it simple. There's a reason it has stuck around >inb4 it isn't simple it is

No one chooses to use git. They don’t say: let’s use it because it’s simple. It’s really the only choice because of network effects. It’s one of the biggest glaring monopolies in tech. Think about the barriers to entry of a new vcs. GitHub/gitlab support. Ide support.

I choose to use git, over and over again. I hardly use any of its "network effects" but rather its features. So, maybe try to be a bit less general the next time, please.

Re: What comes after Git

#152

Post by chriswarbo »

rswail wrote: post #59

I'd really like issues porcelain that is built over git so that when I clone I get all of the project's history, as well as it being merged with pull requests etc. I hate that the github/lab hosting solutions end up with a central database to keep track of issues, CI, etc. It breaks the whole "distributed" model.

I use https://mrzv.org/software/artemis

Issues are kept in the repo, inside a .issues folder, so they can be cloned, merged, etc. Each issue is just a maildir, with metadata stored as headers on the top-level message, and comments stored as reply messages.

I really like this approach, since there's no need for an always-on server; it's decentralised; I can use any mail client to browse and update the issues (there's also a simple CLI for listing and printing issues/comments); etc. For example, I write artemis issues using the standard message-mode in Emacs, and I render issues to a Web site using MHonArc (a program originally designed to render mailing lists).

Re: What comes after Git

#153

Post by R0flcopt3r »

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?

Re: What comes after Git

#154

Post by knighthack »

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 version control software can be designed for solving a specific problem - but I don't think Git should need to evolve beyond the problems it's designed to take on.

Re: What comes after Git

#155

Post by chriswarbo »

I like the patch-based approach of Pijul and Darcs: rearranging patches seems less fragile than rebasing snapshots.

I'd like to see git's content-based more integrated into projects like IPFS (and for IPFS to get their resource-usage down, so it can be run as a background task on my laptop!)

As for package management, Git and Nix work really well together: e.g. we can use `builtins.fetchGit` to fetch particular commits; and we can `import` Nix definitions from those git commits; and those definitions can fetch other repos, etc. so we get a Merkle tree of the exact code used by all of our dependencies. I also like to write commit IDs as default function arguments, which makes it easy to override any of these dependencies to use another commit.

Re: What comes after Git

#156

Post by knighthack »

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…

I've never understood this sentiment. We're now in 2022. When working on Linux, especially on desktop versions, most people don't need to use the terminal, ever. You could if you want to, but you don't have to.

Similarly, for most things you don't ever have to touch Git on the command line. There are tons of great interfaces overlaying Git - e.g. Sublime Merge, which can visualize what you're doing, and makes Git significantly "nicer to use". You can still descend into the command line, but for whatever you've described above, you don't have to, and you don't have read manpages for common use cases.

Your problem with Git is not an insurmountable issue - it's about finding the right tool to use Git with, and which is the way moving forward anyway. Consider ffmpeg. It's extremely powerful, and about as arcane as git, and you'd needs just as many manpages or Google searches to understand it. Yet most people just use software that overlays all the magical conversions that ffmpeg enables - and no one has to see or blame ffmpeg per se. The scenario should be similar with Git, I hazard.

Re: What comes after Git

#157

Post by maccard »

midenginedcoupe wrote: post #112
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…

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.

Re: What comes after Git

#158

Post by globular-toast »

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…

> Every time I use Git, I see how bad the UX is and marvel at how it ever became popular.

Did you see what came before? Git isn't popular because of its UI, it's popular despite its UI. It's considered worth it because of its distributed model and speed.

Having said that, I've used magit pretty much from the start and can't understand people who don't switch to a better UI eventually. I don't think a command line UI works well for it at all.

Re: What comes after Git

#159

Post by zambal »

> I saw the pain points of git (and GitHub) firsthand working on Kubernetes open-source.

The article could have been interesting if the author actually expanded on what these pain points are. I'm genuinely curious about those.

Re: What comes after Git

#160

Post by pydry »

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?

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.

Post reply on HN