Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

171–180 of 520 posts

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

#171
post #36

Earlier quoted context omitted.

I'm planning on making a hard push for git on the team I just joined (that isn't using any VCS). This and OP are going in my bookmarks.

I'm genuinely curious how they manage source without any VCS. Is it just a bunch of zip files for old versions? No judgment, nobody is born knowing this stuff, just that I'm surprised to hear this is still out in the wild.

Everybody that is not a programmer (or otherwise IT/technical) doesn't understand version control at all. So as other commentators have said, their idea of version control is to save the file with a different name, a different extension, etc.

I have seen it as files on a shared drive. I have seen it as files on a sharepoint drive. I have seen it as files inside of an SVN repository.

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

#173
post #123

Earlier quoted context omitted.

I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do…

> I'm not 100% sure what's going on under the covers. This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.

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

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

#174
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?

Because it's rude and antagonistic and it compels a lot of people to post to defend themselves. It's classic trolling.

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

#175
post #123

Earlier quoted context omitted.

I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do…

> I'm not 100% sure what's going on under the covers. This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.

CLI and GUI are both user interfaces and magic is in the eye of the beholder: if you know your tools, you can predict what will happen under the hood when you click on a button as much as when you submit a command (it's not magic anymore).

Personally, I use the CLI and often have no idea what I'm doing ;)

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

#176
post #57
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…

They can certainly provide much better porcelain out of the box. Mercurial is at least as powerful as git, but I always joked that the learning curve between the two is something like, you read the docs for 5 mins and you'll know what the next 50 commands to type into hg. Whereas git, you spend 50 minutes reading the Pro Git book, just so you know what the next 5 commands should be.

I am glad hg has both Facebook and Google using it. Otherwise Git would have suck the air out of DVCS.

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

#177
post #142

Earlier quoted context omitted.

If you haven't pushed, it's as easy as resetting the branch to the last good commit. If you have pushed, well, it's the same, then push -f, and then making sure that all your teammates pull the fixed branch. If that's a situation you regularly find yourself in, protecting master from direct pushes and only doing PRs is a good solution (GitHub, BitBucket and GitLab all have tooling for this).

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.

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

#178

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…

> One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.

Sorry if I'm being think, but how do you do that? Are you talking about Gblame?

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

#179

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…

"Instead of blaming the tools, you (and your team) should probably learn how to use them."

From the essay:

--------------------

And Git is intimidating, not just to non-technical staff, but also to inexperienced programmers. In How To Destroy A Tech Startup In Three Easy Steps I talk about Sital, and his unwillingness to commit things to Git. He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. He went a month without making a commit, and then he only did so because I insisted. After I put a lot of pressure on him, he got to the point where he would make one commit a day, at night, when he was stopping for the day. He would commit to the master branch, because he was confused how to handle different branches. When there was a merge conflict, I would resolve it for him. We worked together for 6 months, and in that time he learned a great deal about a lot of important topics, but he never really learned how to use Git, because it was a low priority, for both him and our CEO.

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

#180

Earlier quoted context omitted.

Magit in emacs. Probably one of the killer applications for emacs.

+1, along with Tig (console gui).

Thanks for telling me about tig, now I'm justified for having browsed HN today.

It treats my "assume everything works like vim" habit well

Post reply on HN