Hacker News Reader

Comment by P_I_Staker | Hacker News Reader

Disagree that git is hard to use. It's fairly complex, I'll admit, however it's pretty much all "necessary complexity".

Occasionally, I'll see articles talk about "fixing" git by eg. removing the staging area, or something like that... but the staging area is great! It's literally a feature I was dreaming about when I used Mercurial.

I definitely think there's room for a more intuitive solution. I would rate the git learning curve as "medium-easy"

View on HN

Just the ergonomics of git are sometimes mind-boggling. for instance: "git checkout" is used for 3 different things: “switch”, “create branch”, and “revert a file”. Deleting a remote tag is “git push” but a deleting a local one is “git tag -d”. There are many such examples

It's just git's UI is based on operations on the underlying storage instead of workflow intent. From that perspective branch switching and reverting a file are actually similar operations.

For many cases this would be a wrong approach. But git's storage model is quite simple and elegant, and both gives unlimited freedom in adapting it to your needs and could be dangerous if you don't understand it.

When coaching junior devs on git usage I always start with merkle trees, not with a list of commands to remember. This detour takes 20 minutes, but actually gives intuition to fix even worst mistakes without my help when they happen. I can't imagine the same with any other VCS.

yet one often has to google a command, to make sure what is the correct command, even if they know all about the mechanics of the underlying blob storage.

IMO push is quite coherent since it consistently updates remote refs. The variation in checkout is pretty bad though.

The perfect command for deleting remote tag would be "tag -d(elete) -r(emote) <tag>" The existence of "remote refs" is an implementation detail, and git bothers you with it unnecessarily. And if you really need a command to update all remote refs at once why not call it "git sync-refs"? The fact that you use "push" command to delete something is confusing as hell.

> "git checkout" can is used for 3 different things: “switch”, “create branch”, and “revert a file”

Git v2.23 (released in August 2019) added "git switch" and "git restore" commands to straighten this up.

Right. The git porcelain is baffling, but the actual git data model doesn't need fixing; it's complex but necessarily so. I'd be more interested in an alternative porcelain than a totally different VCS like FB's Sapling.

Honestly, the examples you gave seem to make sense when you understand how git works and the philosophy.

It seems most (all?) interaction with the remote is via sync commands: push/pull/fetch. So why bake it into a different command. Commands like "git tag" interact with your local.

Given the abstract concept of a checkout, as it works in git, none of that is surprising (save for maybe that you could create a branch); however, that seems like a desirable feature. Why would you want to do a branch create, then checkout after, when you just want it done right away?

EDIT/P.S. Regarding the git "abstract concept of checkout" that I mentioned, but forgot to define. This is a pretty simple concept: switch working copy to on pointed to by branch reference, and new commits will go on that branch (appended to the end of the branch), create new branch if it doesn't exist (but doesn't this require a flag?)... can't you still create with branch if you really want to?

Sorta.

If you started out from a blank slate then git's not too bad to learn; I've taught several non technical people to get to the point where they can at least read a git history and have some understanding of what's happening when.

At my current job though a lot of folks came in from CVS, SVN, and TFS and it's been a struggle for many. TFS for instance encourages committing large binaries so when they were migrated onto git, their repos were as large as 50 gigabytes because they have every binary from every release from way back when. I've found they actually need someone to explain why git does the things it does, otherwise they have a very wrong mental model of what's going on. And git's confusing terminology doesn't help at all.

Though once it clicks, it just clicks for the most part.

I sometimes think that staging area could be represented as a special WIP commit instead. Non pushable, automatically squashing. This potentially could cut amount of commands to learn by third. But of course I'm missing something important.

That's actually doable and is what HighFlux is doing.

That would certainly be simpler. You could also roll back to any commit.

Yes. The staging area is for prepping the current commit set. I can pick or exclude which changes to go into the next commit. May be if it’s renamed to Change Set people would feel better.

Reply on news.ycombinator.com