4 ms·

This 'reference' is, at best, full of inaccuracies and incorrect terminology, with diagrams that are overly complicated and ridiculous. For example: http://mark

by erso 14y ago

This 'reference' is, at best, full of inaccuracies and incorrect terminology, with diagrams that are overly complicated and ridiculous. For example: http://marklodato.github.com/visual-git-guide/merge.svg http://marklodato.github.com/visual-git-guide/merge.svg. What the fuck? This guide will only make your understanding of Git worse. It uses incorrect terminology to mislead what Git is actually doing in a number of situations, starting with the first sentence of the first section: The four commands above copy files between the working directory, the stage (also called the index), and the history (in the form of commits). Git doesn't care about files, but changesets so this should raise a red flag with anyone with even a passing knowledge of how Git works. This is either a fundamental flaw in the understanding of how Git works by the OP or intentionally misleading wording. In the Commit section, the OP writes: It then points the current branch to this new commit. I don't like this wording because it makes it seem like a branch is something other than a reference to a particular commit (which is available in .git/refs/heads). Really, any reference to "current branch" should be replaced by HEAD, because the current branch is nothing other than HEAD, and HEAD of course is just a commit. In the Checkout section, the OP writes: The checkout command is used to copy files from the history (or stage) to the working directory, and to optionally switch branches. This is blatantly false. `git checkout` doesn't "copy files"; it may move HEAD or it may get rid of any changes in the working directory, and in doing so may change the state of the files within the local repo. In the Committing with a Detached HEAD section, the OP writes: Once you check out something else, say master, the commit is (presumably) no longer referenced by anything else, and gets lost. This is only partly true. The commit still remains in the reflog and can be retrieved up to the point that garbage collection is run. It's incorrect to tell someone their commits are lost as soon as they `git checkout` another treeish. This guide should be binned in favor of EdgeCase's Git Immersion (http://gitimmersion.com/ http://gitimmersion.com/) and Scott Chacon's Pro Git (http://www.git-scm.com/book http://www.git-scm.com/book).

kschrader 14y ago
Perhaps you (or someone else with a better understanding of git) can fork https://github.com/MarkLodato/visual-git-guide https://github.com/MarkLodato/visual-git-guide and clean it up then. I think that it would be interesting to reread this after it's been worked over by someone to better represent the way that Git actually works.
- erso 14y ago
  The thing is, I don't think it's necessary. This guide doesn't aim to add anything that Pro Git or Git Immersion don't already provide. I've tried to avoid adding additional noise to the mountains of Git documentation out there unless I feel there's real value being added, which I hope is the case with my own series of Git-related blog posts (http://pivotallabs.com/users/khicks/blog http://pivotallabs.com/users/khicks/blog).
  - gbog 14y ago
    Agree with your amends to op but not with your last point. This article has flaws but has some good parts. If corrected it could be useful for users with some experience of git but want a deeper understanding, and have no patience for a very detailed textbook.
pokeylope 14y ago
I disagree on most of your points. > Git doesn't care about files, but changesets so this should raise a red flag with anyone with even a passing knowledge of how Git works. This is either a fundamental flaw in the understanding of how Git works by the OP or intentionally misleading wording. Git absolutely cares about files. It cares about commits too, but a commit is mostly just a set of files with a pointer to its parent. The commands being discussed operate on individual files except for commit, which operates on the entire index (which is, conceptually, a snapshot of file). > In the Commit section, the OP writes: It then points the current branch to this new commit. I don't like this wording because it makes it seem like a branch is something other than a reference to a particular commit (which is available in .git/refs/heads). Really, any reference to "current branch" should be replaced by HEAD, because the current branch is nothing other than HEAD, and HEAD of course is just a commit. I don't understand your objection to this phrasing. A branch is a pointer to a commit; the statement talks about changing which commit the branch points to. I don't see where it implies anything else about what a branch is. As for "current branch"/"HEAD", using HEAD is more precise in terms of the actual implementation, but "current branch" is just as accurate and more (new-)user friendly. The author does discuss the relationship between the two prior to that point: "The current branch is identified by the special reference HEAD, which is "attached" to that branch." > In the Checkout section, the OP writes: The checkout command is used to copy files from the history (or stage) to the working directory, and to optionally switch branches. This is blatantly false. `git checkout` doesn't "copy files"; it may move HEAD or it may get rid of any changes in the working directory, and in doing so may change the state of the files within the local repo. When used as "git checkout <ref>", this is correct, but that is not what the author is talking about. "git checkout <ref> <file>" or "git checkout -- <file>" does exactly what the author describes, copying files from the given commit or index to the working directory. > In the Committing with a Detached HEAD section, the OP writes: Once you check out something else, say master, the commit is (presumably) no longer referenced by anything else, and gets lost. This is only partly true. The commit still remains in the reflog and can be retrieved up to the point that garbage collection is run. It's incorrect to tell someone their commits are lost as soon as they `git checkout` another treeish. Only partly true, but true enough. The commit isn't irretrievably lost, but the reflog falls more under "advanced usage"; certainly a git beginner shouldn't be making detached commits and relying on the reflog to get back to them.
rlpb 14y ago
> Git doesn't care about files, but changesets Git's first class objects are files, trees and commits. Changesets are never stored, only derived. Git stores snapshots, not changesets. So your statement seems to be a complete contradiction to what Git actually does. > This guide will only make your understanding of Git worse. I am so shocked by your assertion about git and changesets that I don't know how to begin to respond to this.
- erso 14y ago
  Git's first class objects are objects, which you can see on disk: `find .git/objects -type f | head`. These objects represent one of three things: blobs, trees, and commits, wherein a commit is one or more trees, and a tree is one or more blobs and trees. The statement I quoted when I mentioned changesets was talking about copying files between the working directory and the index, which is certainly not the case. What gets added to the index is the collection of trees and blobs that will make up the next commit when it is created. I mean changeset to be the collection of trees and blobs that will make up the commit. There is no "copying" of files here.

by erso 14y ago

kschrader 14y ago

Perhaps you (or someone else with a better understanding of git) can fork https://github.com/MarkLodato/visual-git-guide https://github.com/MarkLodato/visual-git-guide and clean it up then. I think that it would be interesting to reread this after it's been worked over by someone to better represent the way that Git actually works.

erso 14y ago
The thing is, I don't think it's necessary. This guide doesn't aim to add anything that Pro Git or Git Immersion don't already provide. I've tried to avoid adding additional noise to the mountains of Git documentation out there unless I feel there's real value being added, which I hope is the case with my own series of Git-related blog posts (http://pivotallabs.com/users/khicks/blog http://pivotallabs.com/users/khicks/blog).
- gbog 14y ago
  Agree with your amends to op but not with your last point. This article has flaws but has some good parts. If corrected it could be useful for users with some experience of git but want a deeper understanding, and have no patience for a very detailed textbook.

pokeylope 14y ago

I disagree on most of your points. > Git doesn't care about files, but changesets so this should raise a red flag with anyone with even a passing knowledge of how Git works. This is either a fundamental flaw in the understanding of how Git works by the OP or intentionally misleading wording. Git absolutely cares about files. It cares about commits too, but a commit is mostly just a set of files with a pointer to its parent. The commands being discussed operate on individual files except for commit, which operates on the entire index (which is, conceptually, a snapshot of file). > In the Commit section, the OP writes: It then points the current branch to this new commit. I don't like this wording because it makes it seem like a branch is something other than a reference to a particular commit (which is available in .git/refs/heads). Really, any reference to "current branch" should be replaced by HEAD, because the current branch is nothing other than HEAD, and HEAD of course is just a commit. I don't understand your objection to this phrasing. A branch is a pointer to a commit; the statement talks about changing which commit the branch points to. I don't see where it implies anything else about what a branch is. As for "current branch"/"HEAD", using HEAD is more precise in terms of the actual implementation, but "current branch" is just as accurate and more (new-)user friendly. The author does discuss the relationship between the two prior to that point: "The current branch is identified by the special reference HEAD, which is "attached" to that branch." > In the Checkout section, the OP writes: The checkout command is used to copy files from the history (or stage) to the working directory, and to optionally switch branches. This is blatantly false. `git checkout` doesn't "copy files"; it may move HEAD or it may get rid of any changes in the working directory, and in doing so may change the state of the files within the local repo. When used as "git checkout <ref>", this is correct, but that is not what the author is talking about. "git checkout <ref> <file>" or "git checkout -- <file>" does exactly what the author describes, copying files from the given commit or index to the working directory. > In the Committing with a Detached HEAD section, the OP writes: Once you check out something else, say master, the commit is (presumably) no longer referenced by anything else, and gets lost. This is only partly true. The commit still remains in the reflog and can be retrieved up to the point that garbage collection is run. It's incorrect to tell someone their commits are lost as soon as they `git checkout` another treeish. Only partly true, but true enough. The commit isn't irretrievably lost, but the reflog falls more under "advanced usage"; certainly a git beginner shouldn't be making detached commits and relying on the reflog to get back to them.

rlpb 14y ago

> Git doesn't care about files, but changesets Git's first class objects are files, trees and commits. Changesets are never stored, only derived. Git stores snapshots, not changesets. So your statement seems to be a complete contradiction to what Git actually does. > This guide will only make your understanding of Git worse. I am so shocked by your assertion about git and changesets that I don't know how to begin to respond to this.

erso 14y ago
Git's first class objects are objects, which you can see on disk: `find .git/objects -type f | head`. These objects represent one of three things: blobs, trees, and commits, wherein a commit is one or more trees, and a tree is one or more blobs and trees. The statement I quoted when I mentioned changesets was talking about copying files between the working directory and the index, which is certainly not the case. What gets added to the index is the collection of trees and blobs that will make up the next commit when it is created. I mean changeset to be the collection of trees and blobs that will make up the commit. There is no "copying" of files here.