Git in six hundred words

http://maryrosecook.com/blog/post/git-in-six-hundred-words

by monsterix • 11 years ago

286 108 11 years 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• 11 years 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.htm...

zupa-hu2• 11 years ago

Same thought here. The Git Parable is interesting. OP lost me on line 3. I know git was just curious.

nightpool• 11 years 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• 11 years 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• 11 years ago

I remember seeing this posted on HN a few months back.

Here's the link: https://news.ycombinator.com/item?id=8932737 (see the comments for the correct link..)

I remember liking reading it.

bgilroy262• 11 years 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/

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?'

ttty• 11 years ago

almost git internals

jordanpg• 11 years 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.

PuffinBlue• 11 years 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.

chousuke2• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years 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.

phaemon3• 11 years 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).

scrollaway• 11 years ago

Git does not check with the remote unless you tell it to. So "origin/master" points to what master on origin pointed to the last time git contacted the origin remote.

To have git contact the remote again, you can do "git fetch origin" (or just "git fetch"). Then git will tell you your copy is out of date compared to origin/master, if there's been commits on origin since.

If you commit things, then your copy will be ahead of origin/master, so origin/master is what is out of date and you need to git push:

    ~/dotfiles % git status            ✓✗ master:c024cb4 - dotfiles 
    On branch master
    Your branch is ahead of 'origin/master' by 1 commit.
      (use "git push" to publish your local commits)

mattmanser• 11 years ago

Yeah, but your branch isn't up-to-date is it? It's bad wording.

AceJohnny2• 11 years ago

As others have said, you'd need to do 'git fetch' first before 'git status' would report a difference.

The reason git doesn't do this automatically is because, in its simple model, it doesn't waste time trying to connect to the remote 'origin' or any other remotes you may have configured every time you do 'git status', which is most often used to check what you've modified locally.

I can understand why this would be jarring coming from SVN, where you always want to be checking against the remote/server. Since git has a copy of all history locally, remotes are de-emphasized compared to centralized VCSs.

Dewie3• 11 years ago

I think it's safest to assume that any `git` command that doesn't by necessity make a request to the remote repo (like `git {fetch,pull,push}` and others) does not make a request to the remote repo.

NelsonMinar4• 11 years ago

Because git lied to you. When it says "you are up-to-date with origin/master" it did not actually check that it is up to date with the code on the origin. This is one reason why Git is inhumane. It's reasonable that it didn't check with the remote repo, but its misleading use of the word "origin" does not help new users.

JadeNB• 11 years ago

It's reasonable that it didn't check with the remote repo, but its misleading use of the word "origin" does not help new users.

But 'origin' is just the name of the remote repository, not something hardwired into git, right? (Maybe this response is undercut by the fact that it is the default name.)

agumonkey2• 11 years ago

Same reason your OS won't upgrade your packages unless you update the package list from the repository. I can empathize with the confusion coming from SVN.

tootie• 11 years ago

I've used git for years after having spent years with SVN. no one taught me SVN and never really read much documetation. It was so simple and straightforward. Git introduces a lot of new power and features, but nowhere near the cost increase of the learning to use it. FWIW, I always hoped Mercurial would win. It's at near feature parity with git, but is far easier to use.

jordigh2• 11 years ago

I always hoped Mercurial would win.

We're definitely staging a comeback. Mercurial's development is lively and interesting, and with the backing of the likes of Google, Facebook, Mozilla, and Atlassian, we definitely are seeing lots of good stuff in hg.

michaelmcmillan2• 11 years 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• 11 years 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) ✗

michaelmcmillan2• 11 years ago

I stand corrected, wonder where I got that misconception from.

unclesaamm• 11 years ago

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

NelsonMinar4• 11 years 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• 11 years 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• 11 years ago

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

edmccard• 11 years 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• 11 years 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• 11 years 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.)

reuven6• 11 years 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!"

NelsonMinar4• 11 years 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.

paulsutter• 11 years ago

Could you recommend some better online resources for learning git?

logicallee2• 11 years ago

given that you teach it in-person, I feel that if you were to take the time to write an essay you would automatically bring up the hurdles and a lot of people would find it useful. why not go ahead! You can summarize/start here if you want, we'll give you feedback :)

chousuke2• 11 years ago

It may be an issue of terminology.

I personally think git is simple. That doesn't mean it's easy. The issues listed in the GP comment seem to me mostly social. I think the most common problems with git stem from a more general difficulty in working with a branching, asynchronously developed codebase.

About merges... I think rebase is ridiculously overused, and people should use merges more. Clearly a feature branch littered with spurious merges is bad, but often it seems that this is taken simply to mean that merges are bad, and I get the impression that people go to ridiculous lengths with rebase etc. just to preserve an illusion of linear history even in cases where merging would be better.

kelnos2• 11 years ago

Agreed: attempting to teach that git is simple does people a great disservice.

To be very effective and safe using git, you really do need to understand a bit about its inner workings. I find that to be a big weakness of the tool, and it continues to surprise me that it's become as popular as it has. I personally like git a lot, and find it to be very powerful, but it took time and an interest in deep learning to get there.

I can certainly understand that most people might want a simple VCS that's easy to use and makes it difficult to screw up. Git is not that VCS, by any means.

TillE• 11 years 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.

jordigh2• 11 years 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

(Demo begins around 9:10)

agumonkey2• 11 years 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/, 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...

ps: maybe it just fits my brain's inner working, I like to see every details before grasping the abstraction.

phaemon3• 11 years 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• 11 years 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.

mberning• 11 years 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.

chx• 11 years ago

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

WorldWideWayne• 11 years ago

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

zedadex• 11 years ago

Hear, hear.

Cyberis• 11 years 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• 11 years ago

I see a blank page.

Is this a joke I don't get?

edit: https://i.imgur.com/TQxyQES.png

meta-coder• 11 years ago

Probably due to HTTPS Everywhere. Try disabling the rule for Fonts.net.

zackmorris• 11 years 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• 11 years 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• 11 years 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• 11 years 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).

amk_3• 11 years ago

I like Source Tree for Windows and Gitg/Gitx on Linux/Mac. Also recommend downloading P4 Merge and setting that up as your default merge tool.

kragen2• 11 years ago

git comes with `gitk` and `git instaweb` out of the box; both of these are point-and-click graphical tools that show you branches, merges, and specific commit hashes.

I think what you're looking for here

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

is basically `git checkout -b newbranch 80238ec` followed by `git commit -a`.

stevewilhelm• 11 years 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• 11 years ago

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

msamwald• 11 years 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• 11 years 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• 11 years ago

Debatable. In the two dimensional space of UI quality vs adoption, git seems to be way out on a frontier.

csomar• 11 years 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.

binarycrusader2• 11 years 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• 11 years 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.

binarycrusader2• 11 years 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.

burkaman2• 11 years ago

With that usage, you don't need to understand the implementation. But in my experience of using Git without really understanding it, there is about a 90% chance of destroying your repository when you try to revert something. I have never had this problem with any other VCS.

I'm sure simple reverting is super easy once you know what you're doing, but you need to know what you're doing.

reuven6• 11 years ago

You might very well be right. It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.

I've never used it, but I've heard that Mercurial offers most of the power of Git, with much less of the pain, and an easier user interface. I'm willing to believe that this is true. I'll even believe (whether it's true or not) that Mercurial does provide a nice abstraction layer, one that allows you to ignore the underlying implementation.

The thing is, that doesn't matter at this point. Many people (including me) have gotten through the Git learning curve and now find it to be fantastically useful. I'm far more productive with Git than I was with SVN or CVS, and I'm not the only one to feel this way. As a result, you now have an ecosystem of tools, tutorials, books, etc. that all build on Git -- not to mention companies such as GitHub and GitLab that supply (relatively) easy-to-use tools and interfaces.

Also: A large part of Git's power stems from the fact that you're always thinking in terms of commits, and where those commits fit on your repository's graph. I'm not sure how you can abstract away from that, even if it's an interesting idea in theory.

A combination of critical mass (among open-source developers and a growing number of corporations), an ecosystem, and a powerful (if hard to understand) data model has made Git the standard nowadays. It's a crying shame that Git is so hard for so many people to get... but I've found that in my own work, the learning curve was more than worthwhile, and has made me more productive.

lee• 11 years ago

It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.

I've been using git for 5 years now, and I don't have a clear understanding of "its innards". I once read an overview of how it works under the hood and have a vague notion of what's going on.

What are the typical use case scenarios where you need to know implementation details to "avoid disaster"?

I can rebase/merge/push/pull/commit just fine while being ignorant of implementation.

bottled_poe• 11 years ago

Git hides a lot of complexity, instead exposing an unintuitive set of commands to control your data. Multi-user distributed version control is a very complicated problem to which there will never be a simple solution. If you are willing to sacrifice some features, there are probably simpler solutions that would be more fitting with your work process.

brudgers• 11 years ago

I agree. Everyone should do their own cost benefit analysis. Git has a set of features and costs that make it highly suitable for some combinations of organization and project and not so suited for other combinations. There is no silver bullet.

rcxdude• 11 years ago

I think calling the basics of the data model its 'precise implementation' is excessive. It's like complaining about having to learn the precise details of your display server because someone tries to explain to you how windows in a typical window manager work. The underlying model of git is not terribly complicated, is distinct from (but maps reasonably closely to) its implementation, and it makes understanding all the operations on a repo and working directory a lot easier, as well as making it easier to google for help if you get stuck or want to do something new.

iconjack• 11 years 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.

kelnos2• 11 years 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.

kragen2• 11 years 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.

dsjoerg• 11 years ago

i'm just waiting for git to flame out

flushtwice• 11 years ago

Agreed, it's like the perl of vcs. Please go away.

mjrpes• 11 years 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

morpheous3• 11 years 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.

morpheous3• 11 years ago

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

Git in six hundred words

Related Stories