6 ms·

"You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards." "You decide to bring in some more code from

"You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards." "You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means." "You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End." I love git, but simple intros like this hide all the confusing complexity and awkward UI that quickly comes to the forefront when using git for everyday work.

phaemon 12y ago
> "You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards." Imagine you clone a repo. So your version is identical. You now add a couple more commits to master. Now, to make them identical again, all you have to do is upload the new commits, and then get his master branch to update to point to the latest one. Makes sense, right? That's a fast-forward. Instead, what you do is merge your latest commit with the older commit two back, which creates a third commit with identical content to the previous one. That's silly, right? That's why fast-forward instead of merge. > "You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means." Rebase is when you take the content from a chain of commits, and make a completely new chain with that same content, just because it makes it look neater. You then change the branch from pointing at the head of the old chain to pointing at the head of the new. That's all it does. The old chain is still there until it's garbage collected a few weeks later (or you tag it to stop it disappearing). > "You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End." I'm not sure what the fear is here, so I'm not sure what to tell you. Create a test repository with a few commits and change the hashes below for real ones: git checkout master # on master, whew git checkout e34a53 # oh no, detached head git checkout master # it's ok, back on master, whew git checkout 343a34 # oh no, detached head git checkout master # it's ok, back on master, whew git checkout fe34ee # oh no, detached head git checkout master # it's ok, back on master, whew git checkout a567ed # oh no, detached head git checkout master # it's ok, back on master, whew Repeat until you're not panicking? :-)
- donatj 12y ago
  I wrote a deploy script for our QA system that checks out the commit hash we want instead of the branch and leaves it in detached head mode. Works awesome. Needless to say our ops guys were not amused and demanded it leave it on a branch. People can be do stubbornly stupid sometimes.
  - phaemon 12y ago
    It does leave some people worried, but I think it's just because they don't understand what it means. Maybe adding: git checkout -B lastdeployed to the end of your script would leave them happier!
davidgerard 12y ago
+1. I want an intro to git that covers all the weird confusing shit newbies meet. I think I've read enough of the travel brochure version.
steveklabnik 12y ago
When I read your comment, I'm imagining Adventure...
- edmccard 12y ago
  >When I read your comment, I'm imagining Adventure... "You run 'git push --force'. You are likely to be eaten by a grue."
dasil003 12y ago
Is this an intro or a summary? Because I don't think there's any easy path to learning git, but there's a path, and it goes through understanding the internals, not memorizing UI idiosyncrasies. The thing about git is that the internals are sensible and cohesive, whereas the UI is a train wreck. This is the opposite of svn where the UI is simple, but the internals are a train wreck.
_yosefk 12y ago
The simpler subset is useful for personal or internal projects, however, so it's useful to have it spelled out. (And BTW my own simple subset is still simpler - no branches, for instance, as it helps people delay merges which IMO they tend to overdo even without branches; also helps people pull and think they "got the changes" without actually running the new stuff. Also, my own understanding of rebases, detached heads etc. etc. is minimal at best and I seriously dislike having to learn that sort of thing and having to keep it in mind.)
reuven 12y ago
I teach courses on Git, and I couldn't agree more. Many of my students have been told that Git is simple, and they just need to know 10 commands. Or they can think about it like SVN. Or that they should push, pull, and that's about it. Which has the effect of (a) making them fear Git, (b) making them feel like they'll never figure it out, (c) and convincing them that they're always on the verge of losing data. I've literally had students at the start of my course refer to Git as "that system that makes me lose files." Once I teach people about Git's objects and data structures, things suddenly become much more obvious to these people. Git becomes less of a mystery. I'm not saying that Git is easy for people to understand or use, because it isn't. It has a steep learning curve -- one which I think is worth the effort. But I think that it does a disservice to Git newbies to try to summarize all of Git's functionality in a short essay, and then proclaim, "See? There's not that much to learn here!"
- NelsonMinar 12y ago
  I would be grateful for your course. I've used git now for 3+ years and still don't feel like I understand Git's objects and data structures. Maybe it's because I didn't finish my PhD.
  - reuven 12y ago
    Finishing a PhD gives you bragging rights, but it doesn't make you any smarter! (Believe me, it took me 11 years to do mine... and I've got the bills and emotional scars to prove it!) I might start to teach courses online at some point, but I'm right now so busy with in-person classes in Israel and China (with a bit in Europe probably happening soon) that I haven't had a chance to consider it. But hmm, maybe... Meanwhile, see my above reply with some suggested resources to learn about and understand Git. I hope that they'll help.
    - mlvljr 12y ago
      misread as " I've got the b*lls and emotional scars to prove it!)" ..still would like to salute that!
  - 12y ago
TillE 12y ago
I spent a few weeks working with Git, taking full advantage of the cool history-rewriting stuff it can do that Mercurial still doesn't quite match. It worked, but it required the most arcane syntax I've ever seen. Then I gave up and went back to Mercurial. It does a much better job with subrepos, and I can actually use it without always consulting a hand-scrawled reference sheet for common tasks.
- jordigh 12y ago
  > that Mercurial still doesn't quite match Mercurial's history rewriting is excellent. Do you know of `hg histedit`, `hg commit --amend`, `hg rebase`, `hg crecord --amend`? If you're using Evolve, there's also `hg uncommit` and `hg amend`, amongst others: https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg (Demo begins around 9:10)
agumonkey 12y ago
Took me many steps to finally internalize enough of git internals (still a tiny bit) to start losing fear and discomfort. I find it very similar to learning the semantic of dynamic languages (python: http://www.pythontutor.com/ http://www.pythontutor.com/, js) where you need to see the data model evolving next to the main `pointers`. It looks obscure but it's not large. Small things aren't easy but not necessarily complex #hickeyism. https://codewords.recurse.com/issues/two/git-from-the-inside-out https://codewords.recurse.com/issues/two/git-from-the-inside... ps: maybe it just fits my brain's inner working, I like to see every details before grasping the abstraction.
mberning 12y ago
You could seriously make an Oregon Trail type game that demonstrates all of the ways you can 'die' using git. It would actually be very educational.

phaemon 12y ago

> "You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards." Imagine you clone a repo. So your version is identical. You now add a couple more commits to master. Now, to make them identical again, all you have to do is upload the new commits, and then get his master branch to update to point to the latest one. Makes sense, right? That's a fast-forward. Instead, what you do is merge your latest commit with the older commit two back, which creates a third commit with identical content to the previous one. That's silly, right? That's why fast-forward instead of merge. > "You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means." Rebase is when you take the content from a chain of commits, and make a completely new chain with that same content, just because it makes it look neater. You then change the branch from pointing at the head of the old chain to pointing at the head of the new. That's all it does. The old chain is still there until it's garbage collected a few weeks later (or you tag it to stop it disappearing). > "You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End." I'm not sure what the fear is here, so I'm not sure what to tell you. Create a test repository with a few commits and change the hashes below for real ones: git checkout master # on master, whew git checkout e34a53 # oh no, detached head git checkout master # it's ok, back on master, whew git checkout 343a34 # oh no, detached head git checkout master # it's ok, back on master, whew git checkout fe34ee # oh no, detached head git checkout master # it's ok, back on master, whew git checkout a567ed # oh no, detached head git checkout master # it's ok, back on master, whew Repeat until you're not panicking? :-)

donatj 12y ago
I wrote a deploy script for our QA system that checks out the commit hash we want instead of the branch and leaves it in detached head mode. Works awesome. Needless to say our ops guys were not amused and demanded it leave it on a branch. People can be do stubbornly stupid sometimes.
- phaemon 12y ago
  It does leave some people worried, but I think it's just because they don't understand what it means. Maybe adding: git checkout -B lastdeployed to the end of your script would leave them happier!

davidgerard 12y ago

+1. I want an intro to git that covers all the weird confusing shit newbies meet. I think I've read enough of the travel brochure version.

steveklabnik 12y ago

When I read your comment, I'm imagining Adventure...

edmccard 12y ago
>When I read your comment, I'm imagining Adventure... "You run 'git push --force'. You are likely to be eaten by a grue."

dasil003 12y ago

Is this an intro or a summary? Because I don't think there's any easy path to learning git, but there's a path, and it goes through understanding the internals, not memorizing UI idiosyncrasies. The thing about git is that the internals are sensible and cohesive, whereas the UI is a train wreck. This is the opposite of svn where the UI is simple, but the internals are a train wreck.

_yosefk 12y ago

The simpler subset is useful for personal or internal projects, however, so it's useful to have it spelled out. (And BTW my own simple subset is still simpler - no branches, for instance, as it helps people delay merges which IMO they tend to overdo even without branches; also helps people pull and think they "got the changes" without actually running the new stuff. Also, my own understanding of rebases, detached heads etc. etc. is minimal at best and I seriously dislike having to learn that sort of thing and having to keep it in mind.)

reuven 12y ago

I teach courses on Git, and I couldn't agree more. Many of my students have been told that Git is simple, and they just need to know 10 commands. Or they can think about it like SVN. Or that they should push, pull, and that's about it. Which has the effect of (a) making them fear Git, (b) making them feel like they'll never figure it out, (c) and convincing them that they're always on the verge of losing data. I've literally had students at the start of my course refer to Git as "that system that makes me lose files." Once I teach people about Git's objects and data structures, things suddenly become much more obvious to these people. Git becomes less of a mystery. I'm not saying that Git is easy for people to understand or use, because it isn't. It has a steep learning curve -- one which I think is worth the effort. But I think that it does a disservice to Git newbies to try to summarize all of Git's functionality in a short essay, and then proclaim, "See? There's not that much to learn here!"

NelsonMinar 12y ago
I would be grateful for your course. I've used git now for 3+ years and still don't feel like I understand Git's objects and data structures. Maybe it's because I didn't finish my PhD.
- reuven 12y ago
  Finishing a PhD gives you bragging rights, but it doesn't make you any smarter! (Believe me, it took me 11 years to do mine... and I've got the bills and emotional scars to prove it!) I might start to teach courses online at some point, but I'm right now so busy with in-person classes in Israel and China (with a bit in Europe probably happening soon) that I haven't had a chance to consider it. But hmm, maybe... Meanwhile, see my above reply with some suggested resources to learn about and understand Git. I hope that they'll help.
  - mlvljr 12y ago
    misread as " I've got the b*lls and emotional scars to prove it!)" ..still would like to salute that!
- 12y ago

TillE 12y ago

I spent a few weeks working with Git, taking full advantage of the cool history-rewriting stuff it can do that Mercurial still doesn't quite match. It worked, but it required the most arcane syntax I've ever seen. Then I gave up and went back to Mercurial. It does a much better job with subrepos, and I can actually use it without always consulting a hand-scrawled reference sheet for common tasks.

jordigh 12y ago
> that Mercurial still doesn't quite match Mercurial's history rewriting is excellent. Do you know of `hg histedit`, `hg commit --amend`, `hg rebase`, `hg crecord --amend`? If you're using Evolve, there's also `hg uncommit` and `hg amend`, amongst others: https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg (Demo begins around 9:10)

agumonkey 12y ago

Took me many steps to finally internalize enough of git internals (still a tiny bit) to start losing fear and discomfort. I find it very similar to learning the semantic of dynamic languages (python: http://www.pythontutor.com/ http://www.pythontutor.com/, js) where you need to see the data model evolving next to the main `pointers`. It looks obscure but it's not large. Small things aren't easy but not necessarily complex #hickeyism. https://codewords.recurse.com/issues/two/git-from-the-inside-out https://codewords.recurse.com/issues/two/git-from-the-inside... ps: maybe it just fits my brain's inner working, I like to see every details before grasping the abstraction.

mberning 12y ago

You could seriously make an Oregon Trail type game that demonstrates all of the ways you can 'die' using git. It would actually be very educational.