7 ms·

Git in six hundred words

286 points by monsterix 11y ago

Ellipsis753 11y ago
The page is just pure white for about 30 seconds before it loads for me. (Gentoo Firefox on Linux.) I don't know why but all the items on the page are positioned off page with "visibility: hidden". Anyway, in case the author sees I thought they might want to know. And if it doesn't load for someone here, wait 30 seconds and it probably will. I can see in the console your fonts are failing to load. Perhaps this is causing the issue?
js2 11y ago
This is perhaps too few words to elucidate git. I appreciate that Ms. Cook links to other articles on her own site that go into much greater detail. However, I still think the best self-contained and relatively brief explanation of Git is "The Git Parable."[1] [1] http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
- zupa-hu 11y ago
  Same thought here. The Git Parable is interesting. OP lost me on line 3. I know git was just curious.
- nightpool 11y ago
  In fact, the Git Parable specifically addresses this articles approach to teaching git in the introduction: "Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying." Makes the 600 words achievement seem less impressive, if you put it in the context of existing git education.
  - billforsternz 11y ago
    I can't agree with this. The 600 word article explicitly does not simply demonstrate some commands and go "tadaaaa". Quite the contrary, it demonstrates some commands and explains how they work, a very impressive achievement for something so terse.
paulvs 11y ago
I remember seeing this posted on HN a few months back. Here's the link: https://news.ycombinator.com/item?id=8932737 https://news.ycombinator.com/item?id=8932737 (see the comments for the correct link..) I remember liking reading it.
bgilroy26 11y ago
This is a cool essay! It's very approachable. I would really like to understand git under the hood one day, but I'm intimidated by how much it does with such a small memory footprint. My group project partner and I were having the toughest time with git last night. I thought we were all ready to walk out the door and then we ended up monkeying around with it for an hour and a half. The atlassian visual guides really helped: https://www.atlassian.com/git/tutorials/ https://www.atlassian.com/git/tutorials/ They're great for people who know the names of all the git commands but who are still thrown off in really basic situations, ie 'Is it merge master? Merge origin master? Merge origin/master? Why does it say already-up-to-date?'
- deleted 11y ago
  [deleted]
ttty 11y ago
almost git internals
jordanpg 11y ago
There is some subset of all VCS software that contains the handful of commands that 80% of coders need 80% of the time. Conceptually, these commands are very nearly isomorphic for individuals making changes to files by themselves. These paragraphs do indeed cover those commands for git, although I can't see why this presentation is particularly useful, even for a beginner. It's just a condensed HOWTO that doesn't actually explain what it's doing. Newcomers would be better advised to sacrifice the 30 minutes and read the first three chapters of the storied git book: http://git-scm.com/book/en/v2 http://git-scm.com/book/en/v2.
- PuffinBlue 11y ago
  As a new user of Git, I cannot support this comment enough. The Pro Git book is a fantastic resource that cleanly and concisely outlines the command AND the conceptual framework upon which Git operates. I strongly recommend that all new users read at least those first 3 chapters, but also the very useful chapters on using GitHub - a website that I have personally found extremely unintuitive to use.
- chousuke 11y ago
  The essay seems to encourage the realisation that nothing really special is happening under the hood, which in my view is important for people who are learning to use git. For six hundred words, I think it does a good job.
- luddypants 11y ago
  And then skip ahead and read chapter 10: git internals. This was really helpful for me to understand the fundamental concepts of git and why it is designed the way it is.
ajays 11y ago
I'm an SVN user, and I'll have to move to git some day, but it's not winning any points for me :-( . I got bit by it recently. I had cloned a repo, and then a few weeks later, did % git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean I assumed the working copy was up-to-date, as git states.... but alas, no. I had to do a "git pull" to get the latest changes. Why doesn't git tell you that your copy is out of date?
- justinmk 11y ago
  `git fetch` and `git push` talk to the remote(s) (if any) that you have configured. Most (all?) other commands are local operations. `git status` compares your working copy to your local `.git/` database. If you want `git status` to compare `.git/` with the state of a remote, you must first `git fetch` the state of a remote into your local `.git/`. And you may have multiple remotes, as well...
- hahainternet 11y ago
  Git maintains a local copy of remote branches (to some extent, I'm not sure of the mechanics) and I believe you can cause it to update that with 'git remote update', 'git fetch' and a couple of other tools.
  - phaemon 11y ago
    If you have a branch called "master", whose HEAD is currently "a4300d840a4d01767cb2e768e51f7e88cb40e8cb", for example, all that means is that there is a text file called ".git/refs/heads/master" which has the contents "a4300d840a4d01767cb2e768e51f7e88cb40e8cb". That's all there is to a branch. Do: cat .git/refs/heads/master in any git repo you have on your machine and see (compare it with 'git log') If you have a remote branch that points to the same commit, all that means is that there is a text file called ".git/refs/remotes/origin/master" which has the contents "a4300d840a4d01767cb2e768e51f7e88cb40e8cb". Again, that's all there is to a remote branch. Well, ok, there's also an entry in your ".git/config" file that gives the URI for "origin" (or whatever you've named your remote server; origin is the default). All these files are just text files. Have a look at them in your favourite text editor (or with less or whatever).
michaelmcmillan 11y ago
Correct me if I'm wrong, but the first couple of sentences seems wrong. Git can only be initiated in an empty directory. Other than that: This is a very short and concise introduction, especially the merging.
- davess1 11y ago
  Nope, git can be initialized in directories with files in them. ➜ ~ mkdir test1 ➜ ~ cd test1 ➜ test1 echo "hello" > hello.ttx ➜ test1 ls hello.ttx ➜ test1 git init Initialized empty Git repository in /home/david/test1/.git/ ➜ test1 git:(master) ✗ git status On branch master Initial commit Untracked files: (use "git add <file>..." to include in what will be committed) hello.ttx nothing added to commit but untracked files present (use "git add" to track) ➜ test1 git:(master) ✗
  - michaelmcmillan 11y ago
    I stand corrected, wonder where I got that misconception from.
    - logicallee 11y ago
      you probably read a git tutorial.
    - mh- 11y ago
      you can't clone a remote repo into a non-empty directory. from `man git-clone`: Cloning into an existing directory is only allowed if the directory is empty.
unclesaamm 11y ago
FWIW, the syntax highlighting is a little overwhelming for me.
NelsonMinar 11y ago
"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.
- davidgerard 11y 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 11y ago
  When I read your comment, I'm imagining Adventure...
  - edmccard 11y 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 11y 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 11y 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.)
chx 11y ago
http://www.sbf5.com/~cduan/technical/git/ http://www.sbf5.com/~cduan/technical/git/ "The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something."
Cyberis 11y ago
That was a completely confusing entry. If I didn't already have a pretty good handle on git, I would be hopelessly confused.
WorldWideWayne 11y ago
I am looking forward to a time when memorizing commands seems archaic.
- deleted 11y ago
  [deleted]
- zedadex 11y ago
  Hear, hear.
Cyberis 11y ago
That was a completely confusing entry. If I didn't already have a pretty good handle on git, I would be hopelessly confused.
shocks 11y ago
I see a blank page. Is this a joke I don't get? edit: https://i.imgur.com/TQxyQES.png https://i.imgur.com/TQxyQES.png
- meta-coder 11y ago
  Probably due to HTTPS Everywhere. Try disabling the rule for Fonts.net.
zackmorris 11y ago
Anyone know of a point and click graphical tool for git? I've seen the branches and merges from the console but if I simply want to take git to a specific commit hash, it can easily devolve into hours of research. I believe the problem here is that even though there are only a finite number of choices (less than a dozen in everyday life) representing what I want to accomplish, there are countless ways of getting there with commands. I just don't remember having these kinds of problems with svn, so I think the difficulty is not conceptual, but due to a poor mapping between the concepts and the interface. I'm thinking something like Apple's Time Machine, where you click a commit and the repo shows up on the desktop as a mounted drive. We could use ordinary tools to edit the image and when it's unmounted it becomes a new commit (or something along those lines).
- fsk 11y ago
  SourceTree (by BitBucket) has a decent GUI Git client. The official github client is trash. The last time I used it was a year ago, so it might have improved since then.
  - niuzeta 11y ago
    Still is.(gave it a try yesterday. Not a lot has changed.) I do like the git-bash on Windows, though. For some reason I've avoided installing cygwin.... ever.
- georgemcbay 11y ago
  I like SmartGit enough that I paid $80 for it (despite the fact that it seems weird to pay money for dev tools these days). You can download it and use it free for non-commercial use, though. I'm reasonably comfortable with the git command-line tools, but for keeping the simple things simple I really do like an integrated all-in-one visual diff/VCS client program and SmartGit is the best one I've used for git. SourceTree (mentioned by fsk) is kind of a trainwreck on Windows, in my experience (moving to SmartGit was the result of me getting fed up with SourceTree and looking for something not as frustrating). From what I understand the Mac version works better, though I haven't used it. While the UI is quite nice to start, the Windows version of SourceTree tends to soft-hang a lot (goes into non-responsive states it eventually recovers from, but will hang for like 30+ seconds at times) and it has a lot of weird issues with multi-monitor setups (it'll sometimes randomly jump to the other monitor during pane resizing and such).
stevewilhelm 11y ago
This might be useful for someone who is managing a personal project on Github. Add a couple of additional developers with 600 words of git understanding would result in chaos.
DougBTX 11y ago
Git in six words: content addressable filesystem with linked revisions.
msamwald 11y ago
For me, the hardest thing about learning Git is the lurking feeling that I have to learn it because it has become an unavoidable fad, not because it is the best approach to version management for most common use-cases.
- AndyKelley 11y ago
  I think your attitude is completely reasonable, and I'm with you on your skepticism. However I am pleasantly surprised that, for once, a software fad lines up with what is actually technically superior. Linus knows how to design software correctly.
  - recursive 11y ago
    Debatable. In the two dimensional space of UI quality vs adoption, git seems to be way out on a frontier.
csomar 11y ago
Fast-forward 5 years into using Git, I learned that git add and git commit is all you need to know to get started. I learned everything else, on the job and by need. - git push when I needed to take work to Github - git checkout when I needed to move between branches - git merge when I needed to merge someone else work into master - git cherry-pick I needed this to take commits from a non-fork to my project - git bissect Debugging a bug introduced between releases I also learned to use Github tools, SourceTree, the Command-Line and Bitbucket. If you want to learn git, just make a commit. Everything else will be mastered down the road.
binarycrusader 11y ago
And here, perfectly illustrated, is a reminder why I don't like using some source code version control systems. I don't want to understand the precise implementation of my source code control system, and I don't personally believe that I should have to for effective use. I realise this is likely an unpopular opinion, but I would challenge you to reply with justification rather than inevitably downvoting me into oblivion. One of my software development mentors (a long time mechanical engineer who has done UNIX OS development for 20+ years) often has this as his email signature and I think it's rather apt in this context: Civilization advances by extending the number of important operations which we can perform without thinking about them. With that said, I'm not advocating complete ignorance of how a version control system "works", I just find the philosophy of "you must learn the internal data formats and workings of this system to use it effectively" more than a bit distasteful.
- ackalker 11y ago
  Just how does using `git init`, `git add`, `git commit`, `git push`, `git merge`, `git pull` force one to know Git's implementation details? Even thinking of Git as a security camera watching your shop (working tree), a VCR (record, forward, rewind history), a videotape copier (branching, pushing) and video editor (pulling, merging) wouldn't be too far off the mark, without the need for any reference to Git's inner workings. Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just as well have been brownies, blurfls, gizmos or whatever, as long as the practical context in which one needs these things is clear. Branches, tags and remotes are still the most useful top-level concepts, with no need for knowing their implementation details. Only when one needs to do really low-level stuff like efficient import/export, history rewriting (ugh) etc. does one need to know a little more about how Git works. Many people have used Git for years without knowing anything about the plumbing beneath its porcelain.
  - binarycrusader 11y ago
    That's why I said it was a "reminder" and not a perfect illustration. Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system. Even then, I personally find Git's interface confusing and inconsistent -- there are various examples of that with how you request help (usage) for various commands. The only way I can personally tolerate using Git at the moment is via SourceTree or the GitHub web interface. That's just my personal opinion of course and isn't necessarily a factual reflection of Git itself. I've used various source code control systems over the years: sccs, perforce, bitkeeper, cvs, svn, bzr, mercurial, and so on to various degrees if that means anything. The one I've finally settled on for personal use has been mercurial, which I've generally found fits my own workflows the best and generally has an interface that seems to work without me having to think about it too much.
dsjoerg 11y ago
i'm just waiting for git to flame out
- flushtwice 11y ago
  Agreed, it's like the perl of vcs. Please go away.
mjrpes 11y ago
I've definitely found git confusing to understand. I've had to write myself a tutorial to get my head around the concepts and day-to-day workflow: http://freetexthost.com/pe020d1b41 http://freetexthost.com/pe020d1b41
iconjack 11y ago
What git needs is a simple undo command, as in git undo and it just undoes whatever you just did. There seems to be a way to undo pretty much anything, but I usually end up googling and deciphering the likes of git reset HEAD hard -f --now origin/master --no-rebase %${%&`+'${`%&NO CARRIER") Then when that goes wrong, you're in real trouble and left scratching your head at git's error message.
- kelnos 11y ago
  Hmm, the reflog usually (always?) provides all the info you need to undo the last action. I wouldn't be surprised if it were possible to build a "git undo" command on top of that. The fact that no one has yet done so is a great illustration of your point, though.
  - kragen 11y ago
    The reflog just lets you undo commits (whether created by `git commit` or rebase or merge or whatever), while actions like `git reset`, `git checkout`, `git add`, `git gc`, and `git rm` cannot be undone with the reflog.
morpheous 11y ago
"It points the master branch on beta at the commit object that the master branch points at on the alpha repository." Yes, as clear as mud. This is why I hate git. Why should code versioning be SO bloody complicated?!. Give me SVN or (shudder) CVS anyday.
morpheous 11y ago
https://www.youtube.com/watch?v=UllNDRXR1vM https://www.youtube.com/watch?v=UllNDRXR1vM

286 points by monsterix 11y ago

The page is just pure white for about 30 seconds before it loads for me. (Gentoo Firefox on Linux.) I don't know why but all the items on the page are positioned off page with "visibility: hidden". Anyway, in case the author sees I thought they might want to know. And if it doesn't load for someone here, wait 30 seconds and it probably will. I can see in the console your fonts are failing to load. Perhaps this is causing the issue?

js2 11y ago

This is perhaps too few words to elucidate git. I appreciate that Ms. Cook links to other articles on her own site that go into much greater detail. However, I still think the best self-contained and relatively brief explanation of Git is "The Git Parable."[1] [1] http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...

zupa-hu 11y ago
Same thought here. The Git Parable is interesting. OP lost me on line 3. I know git was just curious.
nightpool 11y ago
In fact, the Git Parable specifically addresses this articles approach to teaching git in the introduction: "Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying." Makes the 600 words achievement seem less impressive, if you put it in the context of existing git education.
- billforsternz 11y ago
  I can't agree with this. The 600 word article explicitly does not simply demonstrate some commands and go "tadaaaa". Quite the contrary, it demonstrates some commands and explains how they work, a very impressive achievement for something so terse.

paulvs 11y ago

I remember seeing this posted on HN a few months back. Here's the link: https://news.ycombinator.com/item?id=8932737 https://news.ycombinator.com/item?id=8932737 (see the comments for the correct link..) I remember liking reading it.

bgilroy26 11y ago

This is a cool essay! It's very approachable. I would really like to understand git under the hood one day, but I'm intimidated by how much it does with such a small memory footprint. My group project partner and I were having the toughest time with git last night. I thought we were all ready to walk out the door and then we ended up monkeying around with it for an hour and a half. The atlassian visual guides really helped: https://www.atlassian.com/git/tutorials/ https://www.atlassian.com/git/tutorials/ They're great for people who know the names of all the git commands but who are still thrown off in really basic situations, ie 'Is it merge master? Merge origin master? Merge origin/master? Why does it say already-up-to-date?'

deleted 11y ago
[deleted]

ttty 11y ago

almost git internals

jordanpg 11y ago

There is some subset of all VCS software that contains the handful of commands that 80% of coders need 80% of the time. Conceptually, these commands are very nearly isomorphic for individuals making changes to files by themselves. These paragraphs do indeed cover those commands for git, although I can't see why this presentation is particularly useful, even for a beginner. It's just a condensed HOWTO that doesn't actually explain what it's doing. Newcomers would be better advised to sacrifice the 30 minutes and read the first three chapters of the storied git book: http://git-scm.com/book/en/v2 http://git-scm.com/book/en/v2.

PuffinBlue 11y ago
As a new user of Git, I cannot support this comment enough. The Pro Git book is a fantastic resource that cleanly and concisely outlines the command AND the conceptual framework upon which Git operates. I strongly recommend that all new users read at least those first 3 chapters, but also the very useful chapters on using GitHub - a website that I have personally found extremely unintuitive to use.
chousuke 11y ago
The essay seems to encourage the realisation that nothing really special is happening under the hood, which in my view is important for people who are learning to use git. For six hundred words, I think it does a good job.
luddypants 11y ago
And then skip ahead and read chapter 10: git internals. This was really helpful for me to understand the fundamental concepts of git and why it is designed the way it is.

ajays 11y ago

I'm an SVN user, and I'll have to move to git some day, but it's not winning any points for me :-( . I got bit by it recently. I had cloned a repo, and then a few weeks later, did % git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean I assumed the working copy was up-to-date, as git states.... but alas, no. I had to do a "git pull" to get the latest changes. Why doesn't git tell you that your copy is out of date?

justinmk 11y ago
`git fetch` and `git push` talk to the remote(s) (if any) that you have configured. Most (all?) other commands are local operations. `git status` compares your working copy to your local `.git/` database. If you want `git status` to compare `.git/` with the state of a remote, you must first `git fetch` the state of a remote into your local `.git/`. And you may have multiple remotes, as well...
hahainternet 11y ago
Git maintains a local copy of remote branches (to some extent, I'm not sure of the mechanics) and I believe you can cause it to update that with 'git remote update', 'git fetch' and a couple of other tools.
- phaemon 11y ago
  If you have a branch called "master", whose HEAD is currently "a4300d840a4d01767cb2e768e51f7e88cb40e8cb", for example, all that means is that there is a text file called ".git/refs/heads/master" which has the contents "a4300d840a4d01767cb2e768e51f7e88cb40e8cb". That's all there is to a branch. Do: cat .git/refs/heads/master in any git repo you have on your machine and see (compare it with 'git log') If you have a remote branch that points to the same commit, all that means is that there is a text file called ".git/refs/remotes/origin/master" which has the contents "a4300d840a4d01767cb2e768e51f7e88cb40e8cb". Again, that's all there is to a remote branch. Well, ok, there's also an entry in your ".git/config" file that gives the URI for "origin" (or whatever you've named your remote server; origin is the default). All these files are just text files. Have a look at them in your favourite text editor (or with less or whatever).

michaelmcmillan 11y ago

Correct me if I'm wrong, but the first couple of sentences seems wrong. Git can only be initiated in an empty directory. Other than that: This is a very short and concise introduction, especially the merging.

davess1 11y ago
Nope, git can be initialized in directories with files in them. ➜ ~ mkdir test1 ➜ ~ cd test1 ➜ test1 echo "hello" > hello.ttx ➜ test1 ls hello.ttx ➜ test1 git init Initialized empty Git repository in /home/david/test1/.git/ ➜ test1 git:(master) ✗ git status On branch master Initial commit Untracked files: (use "git add <file>..." to include in what will be committed) hello.ttx nothing added to commit but untracked files present (use "git add" to track) ➜ test1 git:(master) ✗
- michaelmcmillan 11y ago
  I stand corrected, wonder where I got that misconception from.
  - logicallee 11y ago
    you probably read a git tutorial.
  - mh- 11y ago
    you can't clone a remote repo into a non-empty directory. from `man git-clone`: Cloning into an existing directory is only allowed if the directory is empty.

unclesaamm 11y ago

FWIW, the syntax highlighting is a little overwhelming for me.

NelsonMinar 11y ago

"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.

davidgerard 11y 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 11y ago
When I read your comment, I'm imagining Adventure...
- edmccard 11y 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 11y 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 11y 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.)

chx 11y ago

http://www.sbf5.com/~cduan/technical/git/ http://www.sbf5.com/~cduan/technical/git/ "The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something."

Cyberis 11y ago

That was a completely confusing entry. If I didn't already have a pretty good handle on git, I would be hopelessly confused.

WorldWideWayne 11y ago

I am looking forward to a time when memorizing commands seems archaic.

deleted 11y ago
[deleted]
zedadex 11y ago
Hear, hear.

Cyberis 11y ago

That was a completely confusing entry. If I didn't already have a pretty good handle on git, I would be hopelessly confused.

shocks 11y ago

I see a blank page. Is this a joke I don't get? edit: https://i.imgur.com/TQxyQES.png https://i.imgur.com/TQxyQES.png

meta-coder 11y ago
Probably due to HTTPS Everywhere. Try disabling the rule for Fonts.net.

zackmorris 11y ago

Anyone know of a point and click graphical tool for git? I've seen the branches and merges from the console but if I simply want to take git to a specific commit hash, it can easily devolve into hours of research. I believe the problem here is that even though there are only a finite number of choices (less than a dozen in everyday life) representing what I want to accomplish, there are countless ways of getting there with commands. I just don't remember having these kinds of problems with svn, so I think the difficulty is not conceptual, but due to a poor mapping between the concepts and the interface. I'm thinking something like Apple's Time Machine, where you click a commit and the repo shows up on the desktop as a mounted drive. We could use ordinary tools to edit the image and when it's unmounted it becomes a new commit (or something along those lines).

fsk 11y ago
SourceTree (by BitBucket) has a decent GUI Git client. The official github client is trash. The last time I used it was a year ago, so it might have improved since then.
- niuzeta 11y ago
  Still is.(gave it a try yesterday. Not a lot has changed.) I do like the git-bash on Windows, though. For some reason I've avoided installing cygwin.... ever.
georgemcbay 11y ago
I like SmartGit enough that I paid $80 for it (despite the fact that it seems weird to pay money for dev tools these days). You can download it and use it free for non-commercial use, though. I'm reasonably comfortable with the git command-line tools, but for keeping the simple things simple I really do like an integrated all-in-one visual diff/VCS client program and SmartGit is the best one I've used for git. SourceTree (mentioned by fsk) is kind of a trainwreck on Windows, in my experience (moving to SmartGit was the result of me getting fed up with SourceTree and looking for something not as frustrating). From what I understand the Mac version works better, though I haven't used it. While the UI is quite nice to start, the Windows version of SourceTree tends to soft-hang a lot (goes into non-responsive states it eventually recovers from, but will hang for like 30+ seconds at times) and it has a lot of weird issues with multi-monitor setups (it'll sometimes randomly jump to the other monitor during pane resizing and such).

stevewilhelm 11y ago

This might be useful for someone who is managing a personal project on Github. Add a couple of additional developers with 600 words of git understanding would result in chaos.

DougBTX 11y ago

Git in six words: content addressable filesystem with linked revisions.

msamwald 11y ago

For me, the hardest thing about learning Git is the lurking feeling that I have to learn it because it has become an unavoidable fad, not because it is the best approach to version management for most common use-cases.

AndyKelley 11y ago
I think your attitude is completely reasonable, and I'm with you on your skepticism. However I am pleasantly surprised that, for once, a software fad lines up with what is actually technically superior. Linus knows how to design software correctly.
- recursive 11y ago
  Debatable. In the two dimensional space of UI quality vs adoption, git seems to be way out on a frontier.

csomar 11y ago

Fast-forward 5 years into using Git, I learned that git add and git commit is all you need to know to get started. I learned everything else, on the job and by need. - git push when I needed to take work to Github - git checkout when I needed to move between branches - git merge when I needed to merge someone else work into master - git cherry-pick I needed this to take commits from a non-fork to my project - git bissect Debugging a bug introduced between releases I also learned to use Github tools, SourceTree, the Command-Line and Bitbucket. If you want to learn git, just make a commit. Everything else will be mastered down the road.

binarycrusader 11y ago

And here, perfectly illustrated, is a reminder why I don't like using some source code version control systems. I don't want to understand the precise implementation of my source code control system, and I don't personally believe that I should have to for effective use. I realise this is likely an unpopular opinion, but I would challenge you to reply with justification rather than inevitably downvoting me into oblivion. One of my software development mentors (a long time mechanical engineer who has done UNIX OS development for 20+ years) often has this as his email signature and I think it's rather apt in this context: Civilization advances by extending the number of important operations which we can perform without thinking about them. With that said, I'm not advocating complete ignorance of how a version control system "works", I just find the philosophy of "you must learn the internal data formats and workings of this system to use it effectively" more than a bit distasteful.

ackalker 11y ago
Just how does using `git init`, `git add`, `git commit`, `git push`, `git merge`, `git pull` force one to know Git's implementation details? Even thinking of Git as a security camera watching your shop (working tree), a VCR (record, forward, rewind history), a videotape copier (branching, pushing) and video editor (pulling, merging) wouldn't be too far off the mark, without the need for any reference to Git's inner workings. Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just as well have been brownies, blurfls, gizmos or whatever, as long as the practical context in which one needs these things is clear. Branches, tags and remotes are still the most useful top-level concepts, with no need for knowing their implementation details. Only when one needs to do really low-level stuff like efficient import/export, history rewriting (ugh) etc. does one need to know a little more about how Git works. Many people have used Git for years without knowing anything about the plumbing beneath its porcelain.
- binarycrusader 11y ago
  That's why I said it was a "reminder" and not a perfect illustration. Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system. Even then, I personally find Git's interface confusing and inconsistent -- there are various examples of that with how you request help (usage) for various commands. The only way I can personally tolerate using Git at the moment is via SourceTree or the GitHub web interface. That's just my personal opinion of course and isn't necessarily a factual reflection of Git itself. I've used various source code control systems over the years: sccs, perforce, bitkeeper, cvs, svn, bzr, mercurial, and so on to various degrees if that means anything. The one I've finally settled on for personal use has been mercurial, which I've generally found fits my own workflows the best and generally has an interface that seems to work without me having to think about it too much.

dsjoerg 11y ago

i'm just waiting for git to flame out

flushtwice 11y ago
Agreed, it's like the perl of vcs. Please go away.

mjrpes 11y ago

I've definitely found git confusing to understand. I've had to write myself a tutorial to get my head around the concepts and day-to-day workflow: http://freetexthost.com/pe020d1b41 http://freetexthost.com/pe020d1b41

iconjack 11y ago

What git needs is a simple undo command, as in git undo and it just undoes whatever you just did. There seems to be a way to undo pretty much anything, but I usually end up googling and deciphering the likes of git reset HEAD hard -f --now origin/master --no-rebase %${%&`+'${`%&NO CARRIER") Then when that goes wrong, you're in real trouble and left scratching your head at git's error message.

kelnos 11y ago
Hmm, the reflog usually (always?) provides all the info you need to undo the last action. I wouldn't be surprised if it were possible to build a "git undo" command on top of that. The fact that no one has yet done so is a great illustration of your point, though.
- kragen 11y ago
  The reflog just lets you undo commits (whether created by `git commit` or rebase or merge or whatever), while actions like `git reset`, `git checkout`, `git add`, `git gc`, and `git rm` cannot be undone with the reflog.

morpheous 11y ago

"It points the master branch on beta at the commit object that the master branch points at on the alpha repository." Yes, as clear as mud. This is why I hate git. Why should code versioning be SO bloody complicated?!. Give me SVN or (shudder) CVS anyday.

morpheous 11y ago

https://www.youtube.com/watch?v=UllNDRXR1vM https://www.youtube.com/watch?v=UllNDRXR1vM