Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

331–340 of 520 posts

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

#331

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…

Seconded for a GUI. I've been using gitkraken for almost a year now, never looked back.

(full disclosure: as of last week I actually work for the company behind gitkraken but I started using it far before I realized they were local)

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

#333
post #40

I always fight for people really learning git, because that's when it finally starts to get good. And I always tell people that git is not the tool that everybody should use. Most people just need a simple data storage with diff management, like Dropbox or SVN. But even after nearly 10 years, the pressure from the aint-nobody-got-time-for-that crowd is still there. I really, really hope that the git devs don't feel p…

Creating a sane and consistent UI for “git” is not the same as limiting its power.

They could have had every feature they do today without creating weird differences in options and terminology between sub-commands, and they could have set better defaults.

There needs to be an official “git 3” rethinking of options and defaults to solidify the foundation for the years to come and promote widespread adoption. Anything that simply tries to improve “git” as a layer on top will fail due to obscurity.

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

#334
post #142

Earlier quoted context omitted.

Maybe it's just me but I feel like if you work with multiple developers you should never, ever force push master. I'm wary of force pushing branches in general, unless that's a branch that only I work on.

It's not ideal, at all -- and if someone else has pushed in the meantime, they risk losing the commit. But if you're in a situation where doing this would be a significant problem, you should probably not be pushing directly to master in the first place, instead relying on a PR workflow.

Why not simply push a second commit that reverts the broken commit? This will avoid rewriting history and messing up the rest of your team.

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

#335
post #67

Earlier quoted context omitted.

Most of these have nothing to do with git, but are true of any distributed repository. At that point, your argument becomes: distributed repositories are bad for business. Then there's this: > Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion. What rubbish. The features of subversion are a subset of git, and the git equivalents a…

To be fair, git is the first VCS I've ever used where there was any real learning curve at all for normal, everyday use. I don't recall anyone ever really teaching me subversion, outside of maybe 5 minutes walking through the GUI. With git I feel like it probably took a few months of regular use before I felt comfortable with it. That doesn't mean that I'd go back to subversion, but I don't think it's fair to say it'…

I remember trying to do merges in SVN years ago, it was so hard my team agreed to just never make new branches. Git it so much easier to use, it seems hard to compare.

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

#336

The fact web pages like this exist, and are popular, and make it to the top of Hacker News is all you need to know about git's ease-of-use and mental model. That Perforce and SVN don't get such things should also tell you something. (Which isn't to hate on git--it's a great tool.)

Threads like this are a nice reminder of how nice it is to use Perforce. There's no such thing as getting yourself into a bad situation. Not even for artists or designers.

Git has eleventy million blog posts trying to explain how simple it is to use. That's a clear sign that it is, in fact, not simple or easy.

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

#337
post #86

Earlier quoted context omitted.

> I think anyone who uses the CLI is either trying too hard Why do you think it's okay to share this opinion?

What makes you think it is not?

It's not constructive, who cares what you think about CLI users? The fact I'm being downvoted says a lot about the state of this forum.

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

#338

The fact web pages like this exist, and are popular, and make it to the top of Hacker News is all you need to know about git's ease-of-use and mental model. That Perforce and SVN don't get such things should also tell you something. (Which isn't to hate on git--it's a great tool.)

Threads like this are a nice reminder of how nice it is to use Perforce. There's no such thing as getting yourself into a bad situation. Not even for artists or designers. Git has eleventy million blog posts trying to explain how simple it is to use. That's a clear sign that it is, in fact, not simple or easy.

Reminds me of all articles attempting to explain how simple monads are

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

#339

Earlier quoted context omitted.

On the other hand, doing it is the only way you're going to learn. Just do it in a safe environment, with a snapshot of the repository.

Yep. That is the important tip, right here. $ pushd .. $ cp -a my-project my-project-before-I-did-git-surgery $ popd Then relax. This is extremely important before playing with nasty Git surgical tools such as huge rebases. Borked it up? $ pushd .. $ rm -rf my-project $ cp -a my-project-before-I-did-git-surgery my-project $ popd Undo is a great thing, and it's also important to triple check the entire state of the re…

>If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever.

I disagree. I don't have much experience using git with big teams, but at least for small team where a developer usually owns a feature branch, force pushing to the branch to take into account criticism on commits can be helpful. Of course, in that case, feature branches are considered non shared.

Git own "next" branch is actually force pushed to all the time, to remove patches which didn't make the cut for example.

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

#340

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…

You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks. I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split. However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don…

  > Fugitive
That's interesting. I switched back from emacs to vim (neovim), and fugitive was recommended. it just looked like :commands for the normal git cli... maybe I missed something.

So even though I edit in vim, I jump back to emacs for magit for bigger commits or multiple smaller commits (where I need to see diffs to be sure I capture my changes).

I have desired something as useful in vim, but I didn't think there was anything. I'll take another look at fugitive.

Post reply on HN