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

Git is too hard

changelog.com

Post reply on HN
Print view View original

531–540 of 821 posts

Re: Git is too hard

#531

Post by u801e »

rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

> The underlying technology of git is great, but the UX is terrible.

I think it really comes down to a difference in philosophy in terms of learning how to use tools. In the past, one had to read the documentation to figure out how to use a tool. So, for instance, running git --help or git branch --help would give the information needed.

Now having a what's considered an intuitive interface is expected, which is why many people have problems using tools where the documentation is there, but people don't want to take the time to read it.

Re: Git is too hard

#532

Post by simiones »

kernelbugs wrote: post #513
simiones wrote: post #447

Earlier quoted context omitted.

As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency. I…

Could you not perhaps git fetch && git rebase origin/master (for instance, to pull remote changes into a local development branch)?

git fetch && git rebase origin/master, which is equivalent to git pull --rebase origin master, requires your worktree to be clean, so you must either commit or stash if you have any local changes.

Re: Git is too hard

#533

Post by tasuki »

ivanhoe wrote: post #381
rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

> the complexity of the model

Git might not be easy, but it's not complex, it's simple. There are basically only four concepts: blobs, trees, commits, and refs. Which systems (not just version control - systems in general) are simpler?

Re: Git is too hard

#534

Post by crispyambulance »

balabaster wrote: post #529
rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

The biggest hurdle I had to learning Git, if truth be told, was my own aversion to doing anything that wasn't easy. It seemed difficult, so I dug my heels in and say "No! I don't wanna! It seems like friction and that's too hard." The fact is, once I got over myself and sucked it up and got my head around it, it really only took 2 days of effort to grok what I was doing and now it's easy. So biggest advice I can offe…

We have no choice but to "get over it and get on with it". But it DID NOT have to be that way, and that's what makes many people keep their resentment. It's like a kind of "hazing" experience.

Thankfully there are tools that make it less horrible. Git Tower and Visual Studio integration come to mind as examples.

It's sad, however, that there's not been an overhaul of the git commandline into something coherent and usable.

Re: Git is too hard

#535

Post by kristopolous »

bollu wrote: post #192
anotherevan wrote: post #139

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217

While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor. We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does no…

What does simple mean to you?

Re: Git is too hard

#536

Post by atq2119 »

jcelerier wrote: post #477
thrwyoilarticle wrote: post #406

Earlier quoted context omitted.

They're complaining about git and the very first thing they discuss is how git interacts with a completely separate piece of software. Push doesn't have to be to Github, it can also mean sending an email. Obviously you can't undo that. The Github-first problem is viewing git merely as an interface to Github, where the home of the work is and where all things are collected and operated on. From this it follows that gi…

> Obviously you can't undo that. I'd wager I press the "undo" button in gmail at least 3/4 times per week

This only works because you can configure gmail to send email on a timer instead of immediately.

Also, may I kindly suggest that you aren't putting enough thought into your emails? That may be fine for single-recipient emails (depending on your environment), but when your email is received by many people it's an unkind act that shows disregard for the recipient's time and attention.

Re: Git is too hard

#537

Post by simiones »

dahart wrote: post #474
simiones wrote: post #459

Earlier quoted context omitted.

If you have a dirty worktree, `git pull --rebase` fails. You need to either commit or stash your local changes. To stash them, you can use git stash. If you decide to commit them, that's ok, but then you also need to learn about `git reset --hard` or `git commit --amend` or `git push --squash` if the changes were work-in-progress. So which would you recommend? Oh, there is also the option of enabling autostash I thin…

If you have to pull while your work tree is dirty, it’s best but not easiest to branch & commit (safest and avoids the possibility of conflicts during pull), or commit & pull with rebase (safe but might have conflicts). In case you weren’t aware, stash is not as safe as other git commands, it doesn’t have the same safety net and reflog support as a commit does. It’s relatively easy to drop stashes accidentally and lo…

It's interesting that you mention branching, because that is another workflow where I feel that I constantly have to reach for stashing - when I simply want to move to another branch (either for a quick bugfix or simply to check something).

Otherwise yes, I know you can relatively easily lose work with git stash (I actually once lost about 2-4 days of work with a P4 shelve, which is an extremely similar feature), but it still seems easier to me than committing and then cleaning up history/resetting if you change your mind about the implementation...

Re: Git is too hard

#538

Post by chokolad »

simiones wrote: post #447
masonhensley wrote: post #443

Earlier quoted context omitted.

Based on my experience - most teams will get by with ivanhoe's list. You additional items are definitely helpful - but the typical team member's workflow won't cross those bridges. Team leads perhaps. There's definitely levels of proficiency, but for a junior or even mid-level dev doing feature work, I think there red flags if they are needing to jump into stash, cherry, etc on a daily basis.

As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency. I…

> As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them.

I usually do all the work in branches anyways, so I'll just create a quick branch and commit it there.

Re: Git is too hard

#539

Post by closeparen »

simiones wrote: post #438
ritchiea wrote: post #432

Earlier quoted context omitted.

I think of log, cherry-pick, stash & blame "quarterly use" commands rather than "daily use" commands. log maybe monthly, the rest quarterly unless you're doing something wrong.

How can you pull without using stash? Do you always commit everything before pulling? You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is. I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does da…

Yes. Doing a “git commit -am savepoint” on a feature branch is not a big deal; it will get folded into the squash merge with everything else in that unit of code review.

Re: Git is too hard

#540

Post by hallgrim »

As usual, in the discussion there are a lot of folks who's advice/opinion boils down to "rtfm" and "it's not the tool, it's you!"

I found working with SourceTree to be a good fit most of the time, after learning via command line for a bit. It keeps me from having to look stuff up, and is much nicer navigable than command line imho.

My problem with such answers is not that I don't want to have to memorize git commands (with all the flag and sub command variations, git config entries etc.).

My problem is that the guys from the discussions about.. ... blender, vector graphics programs, Xcode, rider, gcc, apple notarization command line tools, brew, pip install, the python3 standard library, emacs, vim, the terminal and ssh, my Synology's time machine configuration, my book keeping and tax program, Django library, the c# standard library, my insurance policies, my smartphone, smart home and my Samsung smart tv, ... ... all said that it's not so hard to memorise these few simple steps or commands, and that I should rtfm.

Not sure how useful of a retort that is to the criticism "X is too hard to use".

Post reply on HN