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

241–250 of 430 posts

Re: What comes after Git

#241

Post by flir »

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 model's basically a directed acyclic graph (not a tree), with each edge being the diff between the two nodes it connects. I think the UX could be improved if it built on the language of graphs to make that model more apparent - node, edge, etc.

(I also believe the same thing about SQL and sets).

Re: What comes after Git

#242

Post by hardware2win »

omnicognate wrote: post #188
hardware2win wrote: post #174

Earlier quoted context omitted.

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.

You don't need to learn its internals or read its code. You do need to learn what it does . This is not unreasonable, and is not the reason its interface is a mess.

Previous poster literally writes about implementation details.

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

Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal

Re: What comes after Git

#243

Post by jacobyoder »

b0afc375b5 wrote: post #197
anonymous_sorry wrote: post #175

Earlier quoted context omitted.

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!

I think this is the first time I've heard of switch and restore. Before I moved to magit I always used git checkout and git reset.

Git switch and git restore were introduced in Git v2.23, way back in August 2019. So... they're not brand new in the last few months, but... like you (and another poster) I'm not aware of them, as I had ... 8-10 years of muscle memory before without them around. I'm actually trying to think back to when I first used git... I don't think I learned about it at all until around 2007 - company I was at had a lot of SVN and a couple of the folks on the team were exploring other options. And... IIRC, around mid-to-late 2008, someone at a local Ruby group demonstrated github. But... I'm not sure I actually started using git 'for real' until 2010 or so.

So... there was 9+ years of learning certain commands/styles and... switch/restore weren't part of that.

And I've mostly switched to GUIs for day to day stuff - the Tower Mac client and sometimes the JetBrains git tools. They might even now be using 'switch' and 'restore' for some basic operations behind the scenes.

Re: What comes after Git

#244

Post by andreareina »

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…

Push makes sense to me actually, branches and tags are both aliases to a particular commit. What makes them different is that the branch pointer gets updated on commit, while the tag pointer is (meant to be) static.

But I do in general agree that the cli leaves much to be desired. I really have to give credit to magit for making a git ui that is simultaneously easy to use, powerful, and has actually made me more proficient at using the regular cli (the commands that underlie the operations are echoed so whenever I do something new I take a peek at how it's done).

Re: What comes after Git

#245

Post by hnrj95 »

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…

fwiw, and surely anecdotal, but i don’t know anybody who knows the dark arts of the git cli and uses some client (magit, lazygit, etc) who prefers to use the former

Re: What comes after Git

#246

Post by jacobyoder »

throw-ru-938 wrote: post #144
troppl wrote: post #141

Earlier quoted context omitted.

Are you really sure that is the case here? I think everyone that starts working with git is a bit hung up by its complexity at least for a year, if not more. It seems to me that, as it should be, every professional SW dev has managed to work with git at some point in their life, then. Because git is simply what you will most likely use nowadays. But still, everyone remembers how hard it was to start out. Which is why…

Come on, getting comfortable with a couple of incantations takes people a whole _year_? Because you don't need much more when you're starting out.

Not always, but if you only do some of those incantations a few times per year, and what you remember is that you tended to get them wrong... it's a bit of a pain. This is partially why I switched to GUI clients for day to day. Tower (and maybe others) have an 'undo' which gives me a bit more confidence to try/test out things, because I know if it's wrong I can hit 'cmd-z' and be back where I was (at least until I push!).

Re: What comes after Git

#247

Post by pcthrowaway »

open-source-ux wrote: post #225
sgbeal wrote: post #202

Earlier quoted context omitted.

(A long-time fossil dev here...) Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is abso…

" Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium. " I wonder why so few developers consider the scenario you describe. Git fits the development of Linux. But, a question rarely raised: why is Git considered suitable for small or medium projects?

It's probably why so many people want to learn/use Hadoop and whatever else Big Tech is using to address their massive scale. Premature optimization and resume-driven development.

I actually love git (even for small projects) but it's because I've been using it for so long now; I suspect if I learned another DVCS I'd be using it in isolation, and git works just fine for me

Re: What comes after Git

#248

Post by dan-robertson »

mpermar wrote: post #167

>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level. I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below. Kubernetes didn't brought open-source collaboration to a new level. No matter how relev…

The introduction was indeed pretty cheesy. I read it and thought ‘I bet there will be a load of comments about the introduction instead of the article’ and then I read the rest of the article. Thankfully other comments did discuss the real content of the post.

Re: What comes after Git

#249

Post by B1FF_PSUVM »

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…

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

Yeah, but saying that here a few years ago got you lynched.

Re: What comes after Git

#250

Post by geenat »

sgbeal wrote: post #215
geenat wrote: post #209

Earlier quoted context omitted.

Fair enough, like vanilla git as of today. I do hope someday git and others employ either a git annex or mercurial-style scheme where if it's a large binary file: 1. no diff is performed, and 2. only the latest version is kept within the history. This would blow wide open the possibilities for using Fossil in binary-heavy projects such as machine learning, games, simulation. I could see the SQLite limitation worked a…

> I do hope someday git and others employ either a git annex or mercurial-style scheme where if it's a large binary file: 1. no diff is performed, and 2. only the latest version is kept within the history. That will never happen in fossil: one of fossil's core-most design features and goals is that it remembers _everything_, not just the latest copy of a file. The way it records checkins, as a list of files and their…

Fair enough, thank you for the detailed insight.
Post reply on HN