Skip to Content

Changes for page Getting Started with Git

Last modified by Bastian Triller on 2013/05/21 17:24
From version 92.1
edited by Kieran Kelleher
on 2011/07/27 15:33
Change comment: There is no comment for this version
To version 93.1
edited by Ray Kiddy
on 2011/08/07 02:05
Change comment: add info on testing pull-requests

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.kieran
1 +XWiki.kiddyr
Content
... ... @@ -121,6 +121,16 @@
121 121  
122 122  Internally, git keeps track of text fragments and not files. Why is this? Because the versions are not the point. The diffs are. I can imagine how Linus Torvalds had this idea. He was looking at all the versions of all the files in Linux and all the e-mails of all the diffs. These are two separate worlds. It is conceptually painful to look at every diff, find its source and see how it maps to what now exists. At some point, he must have realized that all he needed was the e-mails. If he had no files any longer, but all the e-mails, he could always reconstruct the files. He would not have to make the conceptual switch from the diffs to the versions and back. Collectively, those e-mails with the diffs defined everything that needed to be said. Quod erat demonstrandum.
123 123  
124 +=== Testing a Pull-Request ===
125 +
126 +It may not be obvious how to do this. If one is a committer, there is a button one can push to automatically accept a pull-request. But is this really a safe thing to do? But how can you get the diffs being suggested? It seems more complicated than it needs to be to merge the branch the pull-request was made from. One can actually use a URL that specifies just the diff. If the pull-request is at https:~/~/github.com/projectwonder/wonder/pull/43, one can do:
127 +
128 +{{code}}
129 +curl 'https://github.com/projectwonder/wonder/pull/43.patch' | git am
130 +{{/code}}
131 +
132 +The curl fetches the diff. Take off the "git am" to just see the diffs. The "git am" merges the diffs. Then you may build and test the pull-request. A normal push will push the code into the repository.
133 +
124 124  === How Easy Are Branches? ===
125 125  
126 126  It may be helpful to realize this. You should become comfortable with branching. In svn, branching is hard but it is not hard in git. If you have a thought, mull over that thought for a few minutes and jot something down, you have done enough to justify a branch and the branch will be not much harder than finding the post-its on your desk, and perhaps easier. Think about when you would have created a branch in svn. For that amount of work and to establish that level of separation, in git you would create a fork, or create a new repository.