Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some bad Git situations and how I got myself out of them

ohshitgit.com

Post reply on HN
Print view View original

121–130 of 352 posts

Re: Some bad Git situations and how I got myself out of them

#121

Post by edem »

eyelidlessness wrote: post #34

I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…

I stopped using a GUI (SmartGit) when I encountered an error which was talking about stashes and something like {0}. I had no idea what the error was. Now I know how these tools work but I think that you can only use them effectively if you learn how they work and how the underlying system works. If you fail to do so you end up with a leaky abstraction which will at some point (and believe me it will) present you with an error message you don't understand and you end up with a problem you can't recover (yet). GUIs are fine but only if you know the ins and outs of the underlying system.

Re: Some bad Git situations and how I got myself out of them

#122

Post by oneloop »

Git is complex and nuanced, and short term purple think it's faster to memorize some commands instead of understanding the fundamentals.

I kept having problems with git, so I read a fucking book on it https://git-scm.com/book/en/v2

I'm not saying I never get into situations I can't get myself out of, but the examples in the oh shit website now look like obviously trivialities.

Re: Some bad Git situations and how I got myself out of them

#123

Post by noufalibrahim »

K0nserv wrote: post #72
eyelidlessness wrote: post #34

I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…

I have to disagree, I've seen people paint themselves into really hard to get out of corners by using GUI tools and not understanding the underlying tool. git GUIs are leaky abstractions that sometimes even change the meaning of core git concepts. I always recommend people start by using git at the command line until the have a solid understanding of how the tool works before switching to a GUI.

Yes. I teach git professionally and when I do, my approach is to stick to describing the nuts and bolts. Once people use it from the command line and get things done, they (usually) understand what's going on pretty well but are annoyed by the nitty gritties of the command line. Then they're ready to move on to a tool of their choice but can always map the actions there back to the data structures inside git so they've never lost. Also, they can always drop back down to the command line for any low level surgery that the client doesn't provide.

I use magit myself for most things.

Re: Some bad Git situations and how I got myself out of them

#124

Post by dozzie »

TickleSteve wrote: post #106
Singletoned wrote: post #96

Earlier quoted context omitted.

> He knows a lot about his domain, sure, but he's no god and there are a lot of areas he knows diddley-squat about.... user interface design for one! And Einstein knew nothing about biology. I'm sure he knows "diddley-squat" about most areas, but as long as he knows a lot about his domain then he's an expert. And he is good at user interface design, and git is a good example of that; it's just not aimed at beginners.…

no, its not a good UI. admittedly "expert" UIs are different from "noob" UIs, but the number of "git magic spell" followers out there mean that it isn't a good UI for the majority of people who use git.

Well, if you treat git as Torvalds intended it in the beginning (framework for building VCS-es) and accordingly limit the discussion to git's plumbing command set, you get a sensibly good UI+architecture that is targeted at programmers that write VCS-es.

Git being operable with a pry bar and repairable with a hammer is a good proof that in this context it's a good design.

Re: Some bad Git situations and how I got myself out of them

#125

Post by K0nserv »

Illniyar wrote: post #7

Actually the easiest thing is simply not to care about how your log looks. If you don't then there are ry only two things you need to know how to do: If you didn't push to origin do an ammend. If you did, revert soft and commit the previous code to revert it (you can also put a stash or patch to apply it back). Which frankly is what the article does, basically.

Having a messy and complex git log is not only about the visuals though. It can make it a lot harder to track down when/where/why bugs and problematic code was introduced. It makes both git bisect and git blame less useful.

Re: Some bad Git situations and how I got myself out of them

#126

Post by crdoconnor »

oneloop wrote: post #122

Git is complex and nuanced, and short term purple think it's faster to memorize some commands instead of understanding the fundamentals. I kept having problems with git, so I read a fucking book on it https://git-scm.com/book/en/v2 I'm not saying I never get into situations I can't get myself out of, but the examples in the oh shit website now look like obviously trivialities.

It's easier to figure out the various workflows you need (most teams need very few - work on feature, sync code, commit/push/issue PR, release) and then scripting them.

I noticed that git errors on my team were almost eliminated when we started doing that - especially once I started adding sanity checks to the git workflows. It also allowed members of the team who previously struggled with git to contribute much more effectively - they'd be rebasing without even necessarily knowing what rebasing was, for instance.

It also meant that the git workflow, if it was version controlled, could also be amended.

This worked out much better than the git course people were sent on.

Re: Some bad Git situations and how I got myself out of them

#127

Post by atemerev »

ubernostrum wrote: post #103
Zelmor wrote: post #39

Is the documentation really that bad? Would it benefit from a technical writer going over it? Is the project open for discussion on changes to the documentation?

Git is like Perl. And not in any of the good ways. Perl 5 -- I don't know enough about 6 to know whether this is still the case -- involved a couple of design decisions which worked well for one subset of people and did whatever the complete polar opposite of "works" is for a different subset of people. One of those design decisions is the famous "there's more than one way to do it". Ask five Perl programmers to solv…

I am a long-time Perl user and also a long-time Git user.

Git is worse than Perl. Perl is just opinionated: despite what you are saying about it is true, you can write working programs and have fun at all levels of Perl mastery. There's a lot to memorize, but you can start coding immediately and do something useful. Also, Perl community is incredibly friendly and helpful.

Not so with Git. If you start without thorough understanding how Git internals work, you will get burned really soon. And more often than not, the only response you'll get is the arrogant RTFM or the link to Pro Git book.

Re: Some bad Git situations and how I got myself out of them

#128

Post by Stratoscope »

eyelidlessness wrote: post #34

I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…

I'm with you. I've been using SmartGit for years and would never go back to the weak sauce of the command line, except for a few odd things that SmartGit doesn't cover (like bisect).

Every one of the tasks in the article is a simple, straightforward operation in SmartGit. Take "I accidentally committed something to master that should have been on a brand new branch!" or "I accidentally committed to the wrong branch!" for example.

Instead of an obscure series of four to six commands, you simply go to SmartGit's log view and drag the branch markers to where you want them. Easy and intuitive.

I know GUI tools are a hard sell for a lot of programmers. I honestly don't understand why. I think it may be the fear that you'd be giving up power, but SmartGit isn't a dumbed-down GUI. It gives you a more powerful set of tools, and much more visibility into the state of your repo.

You're not even giving anything up. You can still use the command line whenever you want, and SmartGit shows you the commands it used to accomplish each task.

Of course you still need to understand the underlying Git concepts to use any GUI effectively, but a tool like SmartGit lets you see those concepts.

Re: Some bad Git situations and how I got myself out of them

#130

Post by lnalx »

breatheoften wrote: post #114
eyelidlessness wrote: post #34

I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…

Its true -- and actually the well designed gui that accurately depicts the graphical state of your local repository makes it far easier to learn the concepts behind git than does the command line. Distributed vc is conceptually nuanced, but not overly complicated -- the complexity of git really is in the interface wherein you are asked to map command line syntax into abstract operations that manipulate a state that y…

Only for iUsers... Really searching for a Linux alternative !
Post reply on HN