Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

91–100 of 520 posts

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

#91
I gave up on rebasing or any form of history rewrite after going through the screw up phase, then watching every dev that came after me do the same at least once.

I realised that treating a git repo like an immutable collection, where existing commits are NEVER mutated makes it far easier to reason about history and nearly impossible to do serious damage.

Devs can do whatever they please with their own local pulls (such as squashing 50 rambling commits during dev), but once a commit is on remote, it never changes.

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

#92
post #20

The very existence of such guides tells us a lot about how easy to use Git is :)

Name me any software that doesn't need a guide like this.

like, how do you even exit vim? You need a guide for that. Or to get it closer to git / this guide, how do you undo / redo?

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

#93

In three years of using git I believe there is a single bad command that I could not undo: `git checkout -- somefile` The second worst thing I did is losing a commit in a `git rebase -i` but I was able to find it back with `git reflog`. Which makes me think that git is really well designed.

The underlying system is well designed, but a user interface that allows you to get into a point where you can hose a repo is anything but.

The user interface should allow you to do anything you want, but warn you properly. In my experience, this is what git does if you’re about to do something dangerous.

How can you blame git for deleting stuff if you blindly pass --force to it?

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

#94
Good thing HN doesn’t have memes, otherwise I would post one of those bears confessing “I’m a software engineer with 19 years of experience and I still don’t really understand git”.

Silliness aside, I guess Git suffers from the trait that it is very hard for many people to internalize and visualize how it works in their heads. Totally different but related: the Azure CLI is for some reason 10x easier to work with than the AWS CLI, while I’m 10x more experienced with AWS. I guess CLI design is also design.

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

#95

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 don't trust GUI clients; it's easy to not be able to discern the current status, easy to just commit all changes, some of the clients don't respect the pre-push hook, and I've seen other colleagues who have no clue what they're actually doing end up mixing pull and pull --rebase, somehow managing to make duplicate commits with slightly different contents and not having a clue what's going on. Don't use clients if y…

> it's easy to not be able to discern the current status

Probably a failure of whatever UI you're using. I manage just fine.

The common statement from CLI types is that "it's just whatever you're better at using" which is true conceptually, but practically, again, CLI users make more mistakes either from fat fingers or lack of understanding of git.

Understanding git conceptually from a UI point of view is easy. You don't even have to have a full understanding of git to be effective at using it, if the UI is good. I'm shit with the git CLI, but I understand what git is doing.

Yes it's easy to do dumb shit in a GUI, the same is true for CLI. In fact, it's less likely that there'd be a button for doing something dumb than it is that a git novice would find some command on StackOverflow and attempt to use it without fully understanding the ramifications of it.

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

#97
post #31

We pushed large binaries into our git in the past. This was fine-ish as long as Git was hosted inhouse, but now that it's SAASed out, they are a huge pain in the rear. I've browsed through a few git guides, but can't seem to find anything that would let me: 1) Do something like "du -s *|sort -n" for the entire Git history 2) Let me "rm -rf --from-history-too", that would cause the remote repo to actually shrink in si…

You'll be rewriting history via filter-branch, e.g. everyone would need to do the same for the clone and be sure not to push up the old history: https://help.github.com/articles/removing-files-from-a-repos...

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

#98

In short: | Oh shit, I do before I think

Yeah that explains a lot of git mishaps - typos, a missed `--`, `master` vs `origin master` vs `origin/master`, `reset` vs `checkout`, that kinda thing. A lot of things that can go wrong with subtle mistakes, and a lot of things that can go wrong thanks to muscle memory.

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

#99
post #67

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…

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's as easy to use.

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

#100
post #86

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 Why do you think it's okay to share this opinion?

Because this is a forum and nothing I say matters.
Post reply on HN