Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

221–230 of 520 posts

Re: Oh shit, git: Getting myself out of bad situations

#221

Earlier quoted context omitted.

GitHub's GUI is the worst. It has a "sync" button. As soon as I saw that button I knew I'd have trouble using it.. what will "sync" do? Push my branches? Pull tracking branches? Will merge commits get implicitly created? Or will it just fetch? From what servers? I didn't want to risk having my local master get pushed into production just because GH wants to make things easy for me, so I just quit it and went back to…

It just pushes the current branch afaik.

So it never pulls updates on the remote? That seems like pretty unexpected behaviour.

Re: Oh shit, git: Getting myself out of bad situations

#222

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.

Or, you know, that is irrelevant when the person using a GUI makes fewer errors than those who aren't (which has broadly been my experience as well).

Even someone who perfectly understands git can make a typo or have a brain-fart of a day. A GUI significantly reduces the chances of something like that for all users.

Sometimes dev obsession with tool purity does more damage than good.

Re: Oh shit, git: Getting myself out of bad situations

#223

Earlier quoted context omitted.

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.

Yeah, I would guess that the parent commenter has a heavily graphical workflow based out of a big honking IDE like IntelliJ. For people doing development in a console anyway, it would take more time to start a git GUI and wait for it to launch than to be done committing and pushing from the CLI.

The counter argument is that if you make an error using the CLI, you end up spending more time fixing it than if you just had the GUI open and watching your repo already, and simply switch to it when you need to commit/push.

Re: Oh shit, git: Getting myself out of bad situations

#226

I've said this before, but the business leadership, and tech leadership, need to think carefully about whether or not they need all of the power of Git. This sums up my concerns: ----------------------- Here are some minor failure modes I’ve seen with Git: 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood) 2. data is erased for good because someone makes a mista…

> 2. data is erased for good because someone makes a mistake while using rebase No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them. And rebasing generates new commits, leaving the old ones exactly how they were. If somebody lost a commit after a rebase, and nobod…

>If somebody lost a commit after a rebase, and nobody nearby could help them recover it, they should consider spending a few hours learning about git.

GIT is the only source control system where you can completly loose commited data by actions (or commands) available the non-admin user. It's funny to see that this is considered a "feature" and not a design failure.

Re: Oh shit, git: Getting myself out of bad situations

#228

Earlier quoted context omitted.

Almost everything on that list is wrong, but if I point something out (because I actually learned how it works), I'm just a predictable git fanatic? How is that different from burying your head in the sand?

because I actually learned how it works The argument is focused on those who can not learn how it works. See some of the other excerpts from the essay that are in this thread. Also, it's important to note that everything on that list is something that actually happened. Be careful about comparing your advanced skills to people with less skill than you.

> The argument is focused on those who can not learn how it works.

If you're a software developer who uses branches and merges, you absolutely should learn how it works.

If you're an artist, git is not for you. It can neither store large binary files efficiently, nor merge them. There are other VCS that supposedly can, but I haven't tried them.

> Also, it's important to note that everything on that list is something that actually happened.

I can assure you, no data was permanently lost. What did happen is somebody couldn't find it, because they didn't know where to look. And I argue they should have, because git is not really that hard to learn (as a developer).

Re: Oh shit, git: Getting myself out of bad situations

#230
post #161

Earlier quoted context omitted.

Pushing to a remote is a backup. Gitlab offers private repositories for free.

Until you force push ;)

And then you still have the commits, but no branch pointing to them. Don't worry, they're still there.
Post reply on HN