A couple of years ago I decided to make a few small contributions to the Parrot virtual machine project and had to learn Git to do so. I found it somewhat confusing and never felt that I had learned how to use it properly. Then time went by and I forgot everything I'd learned.
About a week aso I wanted to make an improvement to the Django documentation, so it was Git all over again. This time I 1-clicked a copy of O'Reilly's Version Control wtih Git 2/e and started going through it carefully, trying experiments as I went. I found myself confused once again. A bit of thought revealed that it was the index that was confusing me. The book (and other documentation sources) explain the index as a staging area for new files and updates that should appear in the next commit. But I began to find explanations that contradicted this model. In fact, I submitted two errata:
http://oreilly.com/catalog/errataunc...=0636920022862
Once sufficiently annoyed, I decided to start a new project and watch the index as I added files, modified them, and did commits. It turns out that the index is simply a tree of the complete project directory structure with an entry for every file that is part of the current commit. A command like 'add' simply adds or updates an entry in the index. When you do a new commit, Git uses the index to make the commit tree object and then does nothing to the index at all. When you switch branches, it dumps the index and rebuilds it from the commit tree you switched to.
Common on! Why didn't you tell me this from the beginning? Not only is it much clearer, but it doesn't include lies that confuse me later on. Now many things make a lot more sense.
If you look around the Net carefully, you will find some descriptions of the index that are more accurate.
~~ Paul
About a week aso I wanted to make an improvement to the Django documentation, so it was Git all over again. This time I 1-clicked a copy of O'Reilly's Version Control wtih Git 2/e and started going through it carefully, trying experiments as I went. I found myself confused once again. A bit of thought revealed that it was the index that was confusing me. The book (and other documentation sources) explain the index as a staging area for new files and updates that should appear in the next commit. But I began to find explanations that contradicted this model. In fact, I submitted two errata:
http://oreilly.com/catalog/errataunc...=0636920022862
Once sufficiently annoyed, I decided to start a new project and watch the index as I added files, modified them, and did commits. It turns out that the index is simply a tree of the complete project directory structure with an entry for every file that is part of the current commit. A command like 'add' simply adds or updates an entry in the index. When you do a new commit, Git uses the index to make the commit tree object and then does nothing to the index at all. When you switch branches, it dumps the index and rebuilds it from the commit tree you switched to.
Common on! Why didn't you tell me this from the beginning? Not only is it much clearer, but it doesn't include lies that confuse me later on. Now many things make a lot more sense.
If you look around the Net carefully, you will find some descriptions of the index that are more accurate.
~~ Paul
via JREF Forum http://forums.randi.org/showthread.php?t=264346&goto=newpost
Aucun commentaire:
Enregistrer un commentaire