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

131–140 of 275 posts

Re: Oh Shit, Git?

#131

Post by ajross »

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…

> 1. Always use `git switch` instead of `git checkout`

Even harder: always use "git reset --hard".

Basically don't use local branches. The correct workflow for almost every task these days is "all branches are remote". Fetch from remotes. Reset to whatever remote branch you want to work above. Do your work. Push back to a remote branch (usually a pull request branch in common usage) when you're done.

If you need to manage local state, do it manually with tags (or stash, but IMHO I never remember what I stashed and will always make a dummy commit and tag it).

Don't ever try to manually manage a branch locally unless you (1) absolutely have to and (2) absolutely know what you're doing. And even then, don't, just use a hosted upstream like github or whatever.

Re: Oh Shit, Git?

#132

Post by argentinian »

I believe I have a good mental model of what git does, but I never remember commands' arguments to use when they are moderately complex. I mean that the commands are not discoverable or easy to memorize.

I don't know if that's because the text UI is bad, or because it's simply difficult to explain with text what to do to manipulate a tree.

Re: Oh Shit, Git?

#133

Post by maleldil »

wruza wrote: post #81
frakt0x90 wrote: post #73

I'm not proud of it, but my #1 "Oh shit" git operation is to just delete my local repo, reclone, and reapply the changes. Works really well for me 95% of the time. The rest I ask dev ops guy to help.

This should be a built-in git unshit Or git add --unshit -f ~HEAD^^ If you’re using git version <= 2.844.

Jujutsu has `jj undo`, but which undoes whatever was your last jj command, regardless of what it was. It makes much more confident to do an operation I'm uncertain of. And if I regret something many actions down the line, you have `jj op log` (a better reflog).

Re: Oh Shit, Git?

#134

Post by ajross »

baobun wrote: post #106
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…

5. Teaching `git add .` as default to add changes to the staging area is not ideal. Show adding specific files instead has less room for subsequent "oh shit" and better.

True enough, but it does make for good practice with the index and splitting workflows later on when you need to clean it up.

I think there's space for "git add ." as a didactic step. It maps cleanly to the most obvious way to understand a commit, as "here's what I've done". Bootstrapping from that to an understanding of "commits as communication with other developers" will naturally happen over time.

Re: Oh Shit, Git?

#135

Post by compiler-guy »

fragmede wrote: post #120
spokaneplumb wrote: post #91

Earlier quoted context omitted.

I've been using Git for almost 15 years, and have twice built programs/products that use Git internally to achieve certain results (that is, the program/product itself uses Git for things, not just using Git to manage the source code for the program/product) and... sometimes before doing something a little gnarly in Git I'll still just do "cp -R .git ../git-backup" or something like that, so I can replace my entire .…

Reflog is your friend. git break-my-shit git reflog ... output saying where you were before things broke ... grab the good commit sha git reset --hard good_commit_sha_from_reflog

And yet up above we have others recommending to never, ever, use `git reset --hard ...`.

Re: Oh Shit, Git?

#136

Post by riwsky »

dmd wrote: post #34
behnamoh wrote: post #4

Git is one of those technologies that I never got to wrap my head around of, because in so many ways it doesn't follow intuition and unless you have been using it for a long time, for literally every action you would probably have to Google or use the man page of the command.

As everyone knows, though, Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.

Unless you’re in a detached HEAD, in which case it’s xylomorphic to the left-aligned Galois group of R^3.

Re: Oh Shit, Git?

#137

Post by JadeNB »

Terr_ wrote: post #76
lalaithion wrote: post #29

Earlier quoted context omitted.

The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…

> The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild Something I heard somewhere that stuck with me: git is less less of a Version Control System, and more of a toolkit for assembling your own flavor of one.

> Something I heard somewhere that stuck with me: git is less less of a Version Control System, and more of a toolkit for assembling your own flavor of one.

That's how it is in principle, but it seems to me that there aren't that many different CLI "porcelains" in practice. Kind of like how Knuth figured people would essentially write their DSLs on top of plain TeX, not spend most of their time in giant macro packages like LaTeX.

Re: Oh Shit, Git?

#138

Post by bear8642 »

dasil003 wrote: post #108
jimbob45 wrote: post #97

Earlier quoted context omitted.

SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.

svn is perfectly fine and intuitive as long as you never want to branch and merge

huh?

Svn can branch and merge - maybe bit more clunky but still works

Re: Oh Shit, Git?

#139

Post by smrq »

ajross wrote: post #131
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…

> 1. Always use `git switch` instead of `git checkout` Even harder: always use "git reset --hard". Basically don't use local branches. The correct workflow for almost every task these days is "all branches are remote". Fetch from remotes. Reset to whatever remote branch you want to work above. Do your work. Push back to a remote branch (usually a pull request branch in common usage) when you're done. If you need to m…

This sounds like the correct Git workflow if you think the correct VCS to use is SVN.

Re: Oh Shit, Git?

#140

Post by psyclobe »

compiler-guy wrote: post #135
fragmede wrote: post #120

Earlier quoted context omitted.

Reflog is your friend. git break-my-shit git reflog ... output saying where you were before things broke ... grab the good commit sha git reset --hard good_commit_sha_from_reflog

And yet up above we have others recommending to never, ever, use `git reset --hard ...`.

The same people probably want to ban knives!
Post reply on HN