Live data from Hacker News

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

ohshitgit.com

131–140 of 352 posts

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

#131
post #105
post #44

Earlier quoted context omitted.

I agree that it's worth it learning git properly, but sometimes you're thrown into the deep end and don't have the time to get up to speed the "right way". I think git is complicated enough to warrant some simplified descriptions for the most-required tasks.

> sometimes you're thrown into the deep end and don't have the time to get up to speed the "right way". So you don't have three hours to read the fsckin' manual that describes how git repository is organized? O_o

At this point I think we need to define what it means to "learn git properly". The assumption in this discussion is that it is more than learn a few concrete commands for specific tasks in a few minutes. You say 3 hours is sufficient, but is it?

For example, something as simple as "Changing the Last Commit" (as in "git commit --amend") is found in chapter 7.6 in the git book which is given as main documentation on git-scm.org. The first 6 chapter mainly deal with introducing the model, architecture and high level workflows. Even if you skip the chapter on github, that's still 5 chapters on mostly theory to read before you get to some often-used tool commands. I would argue that is more than 3 hours for most people if you don't just skim it but try to also understand it.

Apart from that, to answer the question: indeed, often I don't have 3 hours for something to be considered "nice to know" as opposed to "absolutely necessary". And if the manual is a "fsckin'" one, I'm unlikely to read it at all.

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

#133

Earlier quoted context omitted.

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…

Just ran `brew cask install gitup`, cd'd into my repo and ran `gitup`. Took about 60 seconds and so far it's quite impressive. Clicking on a commit and pressing space brings up a view showing a github-style diff, a list of all changed files, and the complete commit message. Nice. Thanks for the tip!

Happy to share!

I had to do a site visit with a customer recently and spent some time pair programming on their codebase -- on a Windows machine and they used an awful git client -- really reminded me how much I appreciate using gitup!

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

#135

Earlier quoted context omitted.

What are the superior foes in your opinion ? I don't know any of the other distributed version control systems. The only other version control system I have much (too much) experience with is Subversion and it can't hold a candle against Git. In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. Otherwise you have a really great tool with lots of power.

Can you justify git>subversion or are you just following the sheep? Not saying I disagree... but subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups. Just beware of having unjustified-opinions. SVN may not be trendy... but neither will git in a few years time. BTW: Mercurial still beats them all.

>subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups.

For some values of "work". We're using SVN at my new job, with a single trunk branch. Not having the ability to commit locally, and mess around with local branches is a pain in the ass. I found a solution though. I cloned SVN repo using git-svn and now I can make local commits like a pro, and use my beloved magit (Emacs git interface).

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

#136
post #130

Earlier quoted context omitted.

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 !

I don't know how it compares to GitUp, but SmartGit works on Linux, Windows, and macOS. I use it on all three platforms and recommend it highly. See my other comment in the subthread for more thoughts about it.

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

#137

Getting to "Fuck this noise, I give up." is a very clear indication that you aren't competent enough and you should take a GOOD course about git as soon as humanly possible. Shameless plug: http://engineering.hipolabs.com/how-to-work-in-a-team-versio...

If we had to take a GOOD course in every tool that can be used when writing software then we'd have no time to, you know, write software.

Not all people who write software are full-time developers. Not all people who use git are developers at all, come to mention it. Not all people who use git for one thing use it for everything. Not everyone can justify the time required for a course for something that might be a tiny part of their work.

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

#139
post #119

I really like this article but there is a problem with it: what happens if I use one of your techniques and I screw up? These steps you describe are a black box to someone who is no git savvy yet. While these definitely help but they propagate the "git is scary, cross your fingers" mentality. What I mean by this is that the reader won't be any wiser after reading > git reset HEAD~ --hard What is ~ after HEAD? What is…

On the other hand all of these options are well documented in the git book and manual, so it's quite easy to check the details you're not sure about (and learn something new in the process).

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

#140
post #82

Earlier quoted context omitted.

`git rebase -i` by default rebases only back to the first commit you haven't shared (at least that's how I interpret the actual behaviour). This is a great default - it's the simplest way to change history and at the same time powerful without being too dangerous.

Ah, interesting. I'd noticed this behaviour but hadn't conciously thought about it. The docs say: All changes made by commits in the current branch but that are not in are saved to a temporary area. This is the same set of commits that would be shown by git log ..HEAD

If they're not in upstream but they are in another branch, it's still dangerous.
Post reply on HN