Some bad Git situations and how I got myself out of them • Hacker News Board

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

#241

Post by dilap » Fri, Sep 09, 2016, 3:14 PM UTC

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…

Preach! I absolutely love gitup; all of these slice-and-dice operations that are brainteasers in command-line git are just intuitively obvious in gitup. Absolutely one of my favorite pieces of software, ever.

git is basically a brilliant repo model combined with an insane cli. gitup is the brilliant ui that the repo model deserves.

bonus awesome thing about gitup: it monitors the filesystem and updates its state in realtime, so it it's seemless to mix your workflow between cli and gui.

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

#242

Post by kentor » Fri, Sep 09, 2016, 3:18 PM UTC

Hello71 wrote: post #141

lots of these are unnecessarily complicated: > Oh shit, I accidentally committed something to master that should have been on a brand new branch! # disappear the last commit and all changes from it git reset --hard HEAD^ # make a new branch using the last commit git checkout -b new-branch HEAD@{1} > Oh shit, I accidentally committed to the wrong branch! first, you don't need to git-add before and after stash, stash w…

I personally prefer this because old-branch@{1} is a little weird..

  git checkout new-branch
  git cherry-pick old-branch
  git checkout old-branch
  git reset --hard HEAD^

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

#243

Post by Siecje » Fri, Sep 09, 2016, 3:26 PM UTC

theknarf wrote: post #204

coldpie wrote: post #190

Earlier quoted context omitted.

To each his own, of course. As a Git aficionado, I find Mercurial utterly baffling. Branches are permanent and global? You have to clone the repo to make a new thing I would call a branch? "hg log" shows you things that are not in the history of your current source tree? Mind boggling. :)

What git calls branches is most similar to what Mercurial calls tags.

You mean Mercurial bookmarks.

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

#244

Post by atsaloli » Fri, Sep 09, 2016, 3:26 PM UTC

Kratisto wrote: post #239

atsaloli wrote: post #238

There is no substitute for understanding what's going on, especially using a power tool like Git. It's a cute website, and useful, I really like it. This sentence, Bizarrely, git won't do a dif of files that have been add-ed to your staging area without this flag. File under ¯\_(ツ)_/¯" just screams to me (a professional Git trainer), "I don't understand the Git staging area! I don't know my Git fundamentals! Train me…

Any resources you recommend for learning git in more detail?

1. Our "Git Fundamentals: Basic Concepts and Definitions" webinar, http://www.verticalsysadmin.com/git/ (you have to register) lays the groundwork you need to start studying Git.

If you have a team that needs Git training, email me and we can deliver a instance of this webinar (complete with Q&A session) free of charge (as an introductory service).

2. For someone just starting out, I also recommend "Learn Enough Git to be Dangerous", https://www.learnenough.com/git-tutorial (HTML version available for free), from @mhartl, author of the popular RailsTutorial.org

3. The "Pro Git" book is great. https://git-scm.com/book/en/v2 A comprehensive resource.

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

#245

Post by nhaehnle » Fri, Sep 09, 2016, 3:29 PM UTC

dep_b wrote: post #236

Somebody proposed to use a GUI. That doesn't solve the usability issues of Git. There's this triangle of what the user tries to do, what the commands and options are called and what they actually do. None of them really align, though with some careful use you can actually make Git do what you want - eventually. I would like to understand what's the yearly damage of such an important tool being so difficult to use. Pe…

People complain, but what's the alternative?

Non-distributed VCS clearly don't cut it for many use cases, and of the other DVCS I've tried, none were really better than Git in my opinion.

Sure, it depends on your workflow. But if part of your workflow is authoring sequences of commits that make sense in hindsight, then I honestly haven't seen an alternative.

The point of Git is that it gets the underlying data model right, and just exposes that. Once you grok that, it is superior to everything else.

If you don't grok it, you have a problem. For this reason, I think GUIs are actually somewhat detrimental for Git use. git gui and gitk serve a purpose, and they could definitely need some polish, but my other explorations into Git GUIs have basically turned out to be badly done and leaky abstractions which hurt more than they help.

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

#246

Post by shandor » Fri, Sep 09, 2016, 3:31 PM UTC

jryan49 wrote: post #224

mabbo wrote: post #193

One thing not covered very well was what to do if you push to origin. My favourite way to fix this: use git revert to create an exact opposite commit to your bad commit. git revert git push It leaves a history of the mistake, for better or worse, but it does undo the mistake on origin.

Never do this on a merge commit however. Unless you are prepared: https://git-scm.com/blog/2010/03/02/undoing-merges.html

This is why rebase is so, so much better than merge. And it's infinitely better for bisecting, too.

Simple, completely linear history for origin/master is just so powerful in many that aspects that I'm constantly baffled why merging seems to be the flow mostly being talked about.

Now someone usually comes and says that merges are superior for long running branches. Which may be true in some aspects, but when you have more than one "running" branch and you got to try and find which commits have the code changes that only together seem to break and this is after 2 non-trivial merge commits, you really start to wish you'd gone with rebase.

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

#247

Post by runeb » Fri, Sep 09, 2016, 3:32 PM UTC

atsaloli wrote: post #238

There is no substitute for understanding what's going on, especially using a power tool like Git. It's a cute website, and useful, I really like it. This sentence, Bizarrely, git won't do a dif of files that have been add-ed to your staging area without this flag. File under ¯\_(ツ)_/¯" just screams to me (a professional Git trainer), "I don't understand the Git staging area! I don't know my Git fundamentals! Train me…

For people wondering about this: Add --cached or --staged (synonyms) to scope to the staging area.

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

#248

Post by init0 » Fri, Sep 09, 2016, 3:34 PM UTC

for the rest of it there is http://git.io/git-tips

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

#249

Post by sergiosgc » Fri, Sep 09, 2016, 3:35 PM UTC

swehner wrote: post #214

mathieuh wrote: post #20

I absolutely love git now. I'm still at uni (at a highly ranked but actually crap university where we don't learn git properly) and this year was my 'year in industry' as we call it in the UK, and my first proper experience with git, aside from `git init` at the end of my project and pushing it to a repo. I've become so much more confident with git. Seriously, with one caveat (i.e., you haven't pushed your changes to…

I would not expect a university to teach git. Maybe the theory of version control systems, their history, or a comparison of different version control systems. But not how to use the tool.

I agree. Class time is much too valuable to be lost on such minutiae. However, I'd expect a good university to:

a) Explain the value of version control and actively promote its usage

b) Drop some hints on which good version control systems are out there, one of which is git, then let students pick, learn and run with their own choice

It'd take all of half an hour, with great benefits for students.

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

#250

Post by sergiosgc » Fri, Sep 09, 2016, 3:46 PM UTC

zubspace wrote: post #67

wfunction wrote: post #15

Surprised there was nothing on messed-up merges or rebases. They're some of the worst to get out of when you're not totally comfortable with git yet.

Any points on how to continue from there? Been in a few "I give up" conditions during rebases that I completely stopped trusting git it any way. The thing is, some repositories on github require you to commit only after proper rebasing. But I can never in my life remember how and need to google it...

> Been in a few "I give up" conditions during rebases that I completely stopped trusting git it any way.

People use rebase in a far too casual way. Rebasing is a pretty advanced use case, one that is unnecessary for normal git usage. You sentence sounds like: I stopped trusting Ford because the car stopped working when I reprogrammed the ECU.

In short: If you are not entirely comfortable with git's inner workings, do not use rebase. Do not complain if you shoot yourself the foot with rebase.