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

Oh Shit, Git?

ohshitgit.com

Post reply on HN
Print view View original

221–230 of 275 posts

Re: Oh Shit, Git?

#221

Post by extraduder_ire »

kmoser wrote: post #199

> Only amend commits that only exist in your local copy or you're gonna have a bad time. "Gonna have a bad time?" I really wish things like this were explained in more detail, rather than with glib warnings that are unhelpful unless you already know what they mean.

The commit you're amending doesn't exist on your copy anymore, despite existing on the remote that you've pushed to.

Warnings about detaching the HEAD in git are so common that they're kind of assumed to be basic knowledge to a lot of people. Explaining why it's bad if you don't already know would take quite a while too.

I do wish git had some form of warning before you rewrite history that's been pushed somewhere. It should already have all the data to know that.

Re: Oh Shit, Git?

#222

Post by extraduder_ire »

franky47 wrote: post #47

One of the beauties of Git is that as long as you’ve created an object, it’s impossible to lose that work (short of nuking the .git directory). Committing often is key. Precommit hooks (that take more than ~100ms) go against that.

If you orphan the object by not having anything point to it, it goes away when "git gc" is run. That happens automatically after about two weeks by default.

Even things like "git add" will create objects stored in the .git folder.

Re: Oh Shit, Git?

#223

Post by meinersbur »

Avoid `git reset --hard` and `git clean -xfd`. To get a clean working-tree, use `git stash --all`. Allows restoring files if necessary. Saved my sorry bottom multiple times.

Re: Oh Shit, Git?

#224

Post by Am4TIfIsER0ppos »

pitaj wrote: post #3

Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…

git switch is too new and its man page says "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."

Re: Oh Shit, Git?

#225

Post by Am4TIfIsER0ppos »

julienb_sea wrote: post #117

Oh shit, I accidentally `git reset HEAD~1` and moved the last commit to file diffs, which was a merge to master, and my file diff now is both the last branch merge and everything I've done in the last 8hrs. I did this once and it was a gigantic PITA to undo, if anyone has any hot tips for that particular idiocy...

`git reset` again to move to the right commit

Re: Oh Shit, Git?

#226

Post by user4511 »

Oh how I wish more devs would just read the documentation for the tools they pick. I read the git documentation end-to-end. Never really had any issues with it and most commands feels natural to use.

Re: Oh Shit, Git?

#227

Post by megak1d »

SebastianKra wrote: post #46

We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.

Came here to say the same - fork.dev is awesome.

I used to be a CLI git guy but haven't used it in years now

Re: Oh Shit, Git?

#229

Post by qalmakka »

SebastianKra wrote: post #46

We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.

GUI git clients are amazing in the hands of expert users, but terrible for any newcomer that has to actually use Git (and it's not like a designer checking out the source once or twice a month).

The gripe I have is that unless you expose people to CLIs early on, they will just not learn how to use a CLI at all. Whenever something inevitably breaks badly due to GUIs abstracting away how git really works in favour of a nicer UX, they'll end up asking someone that know Git how to fix their mess. And then, it's too late - they already know how to be productive-ish with git and how to deliver something. They can't justify investing time into learning the CLI (especially if they're not that great with Powershell or UNIX shells) so they constantly keep leaning on a colleague instead of learning.

This is not an hypothetical scenario - this really happened regularly at a place I worked at. Innumerable internal training lessons on Git went wasted due to people forgetting everything immediately by using Fork instead of the shell, and then pestering a handful of senior devs. Once IT banned Fork people were forced to use the terminal more often, so they had to learn how to use git for good and actually retained that knowledge via muscle memory.

The adage I've learnt over the course of the years is that the majority of people will go to any length to avoid learning new stuff. It's mentally less tiring to either waste their time doing stuff in an unproductive way than learning new things. IMHO it's better to force people to learn stuff the "right way" early on than let them pick up bad habits and then having to correct them later.

Re: Oh Shit, Git?

#230

Post by blharr »

user4511 wrote: post #226

Oh how I wish more devs would just read the documentation for the tools they pick. I read the git documentation end-to-end. Never really had any issues with it and most commands feels natural to use.

If you memorize the documentation I suppose there's no problem with it, but even then there's confusing things from the beginning design approach.

Like, reset vs revert vs restore, using three similar starting synonyms for different operations.

Reset is particularly confusing because it sounds incredibly destructive, but if you do a soft 'git reset', it just moves the "changes to be committed" to be not staged for the commit.

Then, if you change a single flag (--hard) it is destructive, instead erasing all those changes from your disk.

And there's a reason nobody reads the docs, because they're laid out confusingly at first glance to an unfamiliar person.

If I go to git-scm.com, click docs, the first suggestion is the reference manual. The first guide is on "gitattributes" which gives no philosophy or context as to what it is even used for. Ok, maybe, I'll just check the complete list of git commands... and it starts talking about porcelain and plumbing. Nope, thats not what I need. Maybe try the link "git" under Setup and Config. There the description finally links to a useful "gittutorial" page.

The gittutorial even has some confusing or specific terminology that makes git seem hard. From the beginning of importing a new project "Assume you have a tarball project.tar.gz with your initial work"... why do we need to refer to tar at all, and it doesn't even do the credit of explaining the tar xzf command or what that tarball is. It could easily say 'assume you have a directory', which is the more common case and be 200% more simple.

Post reply on HN