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

471–480 of 821 posts

Re: Git is too hard

#471

Post by theamk »

jrochkind1 wrote: post #341
thrwyoilarticle wrote: post #213

Earlier quoted context omitted.

+1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interac…

I don't see what it's got to do with github. I had the same need, and the same confusion solving it, before I had ever used github, when I used a locally hosted git server of some kind for my team. Do you mean it's a problem only if you are "git push'ing" to a remote shared by those working on a software project? OK, maybe. Even before github, most projects I knew of using git used that method. You can suggest nobody…

If you were before the github, you would not expect an ability to un-push changes. If you were doing development back then, you are likely familiar with "ftp" (or maybe "sftp") and using it to upload files. Or maybe with CSV or SVN.

Question from the blogpost: "I git pushed and I want to undo it"

Compare with: "I uploaded the file on the server with FTP, overriding previous version. How do I undo this?"

Or: "I did 'svn commit', how do I undo this?"

Or: "I have sent an email. How do I un-send it?"

I am not sure where does the original author's expectation that you can undo any action comes from. "thrwyoilarticle" seems to says this is because they started from "github" interface which has nice friendly UI which warns you about actions which cannot be undone. This sounds reasonable to me.

Re: Git is too hard

#473

Post by lhnz »

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…

I've used both but generally don't use stash. I think it's more expressive to have a single commit like "wip: some simple description goes here" and then to `git commit --amend` this until we are happy with its contents.

As well as being more descriptive if you come back after a long weekend, this also means that you can swap branches without worrying that your stash relates to a particular branch but doesn't explicitly belong to this.

Re: Git is too hard

#474

Post by dahart »

simiones wrote: post #459
lionkor wrote: post #453

Earlier quoted context omitted.

`git pull --rebase` ?

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 lose them forever. I’ve seen people do this in production by not being careful when pulling while they have a dirty work tree. The man page for git stash mentions this fact:

“If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms. However, you can try the following incantation to get a list of stash entries that are still in your repository, but not reachable any more:

    git fsck --unreachable |
    grep commit | cut -d\  -f3 |
    xargs git log --merges --no-walk --grep=WIP
”

https://git-scm.com/docs/git-stash

Re: Git is too hard

#475

Post by specialist »

skohan wrote: post #236
protonfish wrote: post #219

Earlier quoted context omitted.

I think that's unfair because I don't see that git even has a UI - it's designed to be a command-line API. The thousands of terrible GUIs out there are so bad that using the command line directly is still the best UI. (I think GitHub has done a great job managing remote repos - I am only talking about local tools.)

A CLI is a UI, it's just a textual one

Yup. Every interface is a user interface.

Re: Git is too hard

#476

Post by cecilpl2 »

eloisius wrote: post #225
dijit wrote: post #211

Earlier quoted context omitted.

Weird question; have you looked at perforce? My previous and current company use perforce but many people (often those who recently join) are decrying that perforce is less elegant than git, but, realistically and based on your own criteria it would be "better" for the connected case. I'm personally a big fan of 'offline/local-first' being a thing, but I'm a sysadmin not a developer.

I’ve had to use perforce before and was not a fan. Granted, I didn’t have to use it full time and can’t claim to be an expert, but I hated the notion of locking files, change lists, yuck. All of it felt so clunky compared to git.

Locking files is critical when you are editing binary data which can't be merged - which in the games industry, is generally how the majority of the dev team works.

Re: Git is too hard

#477

Post by jcelerier »

thrwyoilarticle wrote: post #406
jrochkind1 wrote: post #341

Earlier quoted context omitted.

I don't see what it's got to do with github. I had the same need, and the same confusion solving it, before I had ever used github, when I used a locally hosted git server of some kind for my team. Do you mean it's a problem only if you are "git push'ing" to a remote shared by those working on a software project? OK, maybe. Even before github, most projects I knew of using git used that method. You can suggest nobody…

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

Re: Git is too hard

#478

Post by bntyhntr »

Qwertious wrote: post #408
toopok4k3 wrote: post #309

Earlier quoted context omitted.

Nothing has stopped anyone from creating this perfect GUI(or better CLI) for Git that a lot of people seem to be missing. "Show me the code". Or in this case show me the GUI. Maybe the problem is just actually hard and the Git we have is the best current solution.

Writing a new git GUI doesn't solve the problem, since you need people to adopt it before it's widely installed as default on most OSes by default, and until then you'd probably need to learn the old interface anyway. IIRC there have been various papers on Git's crappy UI and at least one two rewrites (of the interface). Gitless is the name of one. Oh, I forgot the most important thingof all: integration with tooling…

I contributed inconsequential things to Gitless for a very short amount of time years ago. One of the things that I really liked that I ended up rewriting at home was better highlighting, eg inside-the-line level highlighting like github etc. Also maybe it had native support for vertical split? Either way my at-home added that. No idea if that's still in gitless or if anyone else feels that way, but if I'm gonna live the cli life may as well make diffs comfortable for myself.

Re: Git is too hard

#479

Post by henrik_w »

I completely agree that git is hard to learn. I had used both cvs and svn before moving to git, and it took me a looong time to really get git. And it wasn't a case of command line vs GUI - I prefer the command line.

I wrote about some of the things that had to click for me here: https://henrikwarne.com/2018/06/25/6-git-aha-moments/

Re: Git is too hard

#480

Post by rob74 »

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 problem is not the 99% of situations that you can memorize, but the 1% of times when you realize you have made a mistake and strayed from your beaten path into the dark scary unknown Git woods where monsters with detached HEADs may be lurking behind every tree, and you have to ask a coworker or StackOverflow to rescue you...
Post reply on HN