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

191–200 of 275 posts

Re: Oh Shit, Git?

#191

Post by MetaWhirledPeas »

Vampiero wrote: post #146
tantalor wrote: post #38

I'm not a git user, but stuff like this really drives home the idea that "git commit" is meaningless, the only thing that matters is when your commits are pushed or merged. It's like saving a textfile. Do you write a little message every time you save a file? No that's silly. Just move on.

It seems painfully obvious to me that local and remote commits serve different purposes. Local commits are a way to create checkpoints when everything compiles and works and you can move on to the next step. That way you can stash your changes and go back to a working state when you screw things up. Then, before you push those changes, you reset them and split them into proper commits. That way the history is all nic…

I think people would generally have an easier time with git if they didn't try to fix their commit histories and instead just let their past mistakes be known. If you make a bad commit in git the best solution is to follow it up with a good one that fixes the problem. Squash commits on PRs help too.

Re: Oh Shit, Git?

#192

Post by harrall »

dijksterhuis wrote: post #179
harrall wrote: post #170

Earlier quoted context omitted.

Is this really true? When I want to reorder commits, I just drag & drop in a GUI and I’m done. Or if I want to switch branch or manage a complex mix of rebases or cherry picks, it’s just 2 or 3 clicks. In CLI, by the time I’ve typed out the commit hash or locator, it’s already taken longer. And I type 130 words per minute.

> by the time I’ve typed out the commit hash i don’t think i’ve typed out a full hash in … years? if i have i’ve used the short 8 character hash. git rev-parse might be something useful to have a look at, especially when combined with aliases.

Nah I’m talking about the short hash.

But I still have to find the short hash too, and then copy or re-type it… With a UI, I just… click click click done.

Re: Oh Shit, Git?

#193

Post by sundarurfriend »

Silly comment, but:

Every time I see `git reflog`, I see it as re-flog. It's possible that's even the reason I never remember the command, I subconsciously can't bring myself to think of it as "reference log". Instead, it's asking git to sell something cheaply, again.

Re: Oh Shit, Git?

#194

Post by romaniitedomum »

greazy wrote: post #171
gmueckl wrote: post #147

Earlier quoted context omitted.

It is the unquestioningly better tool right now. It's available, stable, battle-tested and it's actively supported. It's a case of "being the change you want to see". Just use it. Claims that it lost are counterproductive. The implicit deterrence from those statements is what is actively keeping Mercurial's adoption low. Hosting is available at least from Sourcehut and heptapod.host. I'm running a private Heptapod in…

Are there any public forges that support hg?

> Are there any public forges that support hg?

Sourceforge, Sourcehut, and GNU Savannah all support Mercurial.

Re: Oh Shit, Git?

#195

Post by wodenokoto »

zahlman wrote: post #183
baobun wrote: post #106

Earlier quoted context omitted.

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.

Learning about the `-p` option for `git add` was one of two things that revolutionized my Git usage. (The other was figuring out how to write effective commit messages.)

This is the main reason to use a GUI imho.

Re: Oh Shit, Git?

#196

Post by seba_dos1 »

fragmede wrote: post #115
lalaithion wrote: post #95

Earlier quoted context omitted.

None of these seem to preclude a command to make an arbitrary branch point to an arbitrary commit without changing anything else.

This works if the branch exists or creates it if it doesn't exist, but not if it's checked out. git branch -f branch_name commit if it's checked out: git reset --hard commit

> but not if it's checked out

...and for a good reason that should be apparent to anyone who understands git's model (HEAD points to a ref in this case, so if you suddenly change what that ref points to without updating the working tree you create an inconsistency).

You can do that manually of course (with `git update-ref` or even a text editor), but then you get to clean up the mess yourself.

Re: Oh Shit, Git?

#197

Post by baobun »

wodenokoto wrote: post #195
zahlman wrote: post #183

Earlier quoted context omitted.

Learning about the `-p` option for `git add` was one of two things that revolutionized my Git usage. (The other was figuring out how to write effective commit messages.)

This is the main reason to use a GUI imho.

Tig is a great one for the terminal fwiw.

gitg for something simple, graphical and widely available.

Re: Oh Shit, Git?

#198

Post by thfuran »

seba_dos1 wrote: post #196
fragmede wrote: post #115

Earlier quoted context omitted.

This works if the branch exists or creates it if it doesn't exist, but not if it's checked out. git branch -f branch_name commit if it's checked out: git reset --hard commit

> but not if it's checked out ...and for a good reason that should be apparent to anyone who understands git's model (HEAD points to a ref in this case, so if you suddenly change what that ref points to without updating the working tree you create an inconsistency). You can do that manually of course (with `git update-ref` or even a text editor), but then you get to clean up the mess yourself.

Couldn't head just detach without any consistency issue?

Re: Oh Shit, Git?

#199

Post by kmoser »

> 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.

Re: Oh Shit, Git?

#200

Post by stackghost »

argentinian wrote: post #132

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.

Both.

Manipulating complex trees via text is not easy, but the text UI is objectively bad:

https://stevelosh.com/blog/2013/04/git-koans/

Post reply on HN