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

131–140 of 430 posts

Re: What comes after Git

#131

Post by kjeetgill »

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.

There's still git fans out here in it's corner!

I feel the same way when I hear griping about vim or Java. Like sure, there's surface stuff to cry about... Until you start to hear people's ideas. Then you're glad people have managed to mostly leave it alone!

I also thing there's just this class of tools that only make sense when you get to a certain level with them. Learning curves are just steep on some things. That's not the same as bad design.

Re: What comes after Git

#132

Post by beermonster »

kardos wrote: post #75
mikewarot wrote: post #39

Earlier quoted context omitted.

>Git is line-oriented and has no notion of semantic diffs and semantic merges. This makes it a raw tool when working with, ironically, source code. Git is a content addressable snapshot system, with bolted on code to make it retrospectively appear to be a line-oriented system. It's worse than you thought.

As I understand it, you can configure git's difftool to be something more clever than line based

See https://tekin.co.uk/2020/10/better-git-diff-output-for-ruby-...

Re: What comes after Git

#133

Post by bilekas »

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.

> You can't learn Git by using its commands.

From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools.

Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.

Re: What comes after Git

#134

Post by tsimionescu »

fargle wrote: post #22
kache_ wrote: post #7

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

agree. same question as "what comes after C ?" same answer.

I'm sure some have written the same about various assembly languages, about COBOL, about FORTRAN, about LISP in AI.

No king rules forever. C has become a much more niche language than it was 20-30 years ago, and the trend continues. C++ has slowly eroded most of its niches, and there's a slew of new languages gunning for its throne - Rust being the most likely to succeed (especially once we will have some popular Linux modules in Rust).

Will there still be a niche for C programmers 50 years from now? Absolutely. Just like there is a niche for COBOL maintainers today.

Re: What comes after Git

#135

Post by tsimionescu »

nathias wrote: post #73

for all complaining about UX, you can make your custom aliases and install extensions (eg. git undo) ...

For all those complaining that this tool box doesn't have any familiar useful tools, you can forge your own tools and use them instead.

Re: What comes after Git

#136

Post by madeofpalk »

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…

> The checkout command is severely overloaded

I guess that's why they split git checkout into git switch and git restore

Re: What comes after Git

#137

Post by Akronymus »

dreamcompiler wrote: post #113
Akronymus wrote: post #49

Earlier quoted context omitted.

I use stashes all the time, when I realize I am working on the wrong branch.

Stashes seem very mysterious to many people. They're one of the most sensible parts of git IMHO. They're just a stack of changes to your files. To me, rebases are the work of the devil and I never use them. To each their own I guess.

> Stashes seem very mysterious to many people.

Huh. For me, they were one of the most intuitive parts of git. Altough, it was a long time before I ever used more than 1 layer of stash at once. (And even then, I rarely do so nowadays)

Re: What comes after Git

#138

Post by bryanrasmussen »

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…

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.

Re: What comes after Git

#139

Post by simias »

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…

Anything can become "fine" with enough practice and muscle memory. I'm a fairly advanced git user and manage to use it mostly painlessly even for relatively advanced tasks but I still think it's pretty crap overall. Not as crap as it was 15 years ago mind you, but not great.

I was a big proponent of Mercurial for a long time because I thought (and still think) that the UI and defaults were vastly superior for most projects which don't have the needs and workflow of the Linux kernel. I gave up a few years ago when it became clear that git was VHS to Hg's Betamax.

Re: What comes after Git

#140

Post by [deleted] »

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…

[deleted]
Post reply on HN