Differences between version 17 and revision by previous author of KernelDevelopmentWithGit.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
Newer page: | version 17 | Last edited on Thursday, November 30, 2006 12:30:34 pm | by IanMcDonald | Revert |
Older page: | version 15 | Last edited on Monday, July 17, 2006 12:22:11 pm | by AristotlePagaltzis | Revert |
@@ -70,8 +70,14 @@
<verbatim>
git-clone -l -s -n sourcedir/.git destdir
</verbatim>
This can be useful if you want to sync up to a new kernel tree and want to minimise downloads.
+
+If you want to make a copy of a remote tree but reuse existing files that are stored locally do something like:
+<verbatim>
+git-clone --reference linus git://git.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.20.git acme-20
+</verbatim>
+This example creates a new git tree which is a copy of acme's remote one, stores it in the directory acme-20 but it also shares files with the git tree in linus. This can be very useful if you keep one tree of Linus' up to date and then keep making copies of other developers trees in this way as they change and can't be pulled easily after they get rebased.
!Using an origin file
If you want to do a git pull without having to specify where to get it from everytime edit the file .git/remotes/origin to be in this format where of course you change the URL:
@@ -85,17 +91,28 @@
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Pull: master:origin
</verbatim>
-!Using git-bisect
+!Using git bisect
+
+To use git bisect go to the bad code first (normally where you are at) and then type <verbatim>git bisect start</verbatim> and then <verbatim>git bisect bad</verbatim>
+
+Now go to a place that is good by checking out code something like <verbatim>git-reset --hard v2.6.19-rc6</verbatim>. If that proves to be good then do <verbatim>git bisect good</verbatim> and then do each change marking good or bad with <verbatim>git bisect good</verbatim> or <verbatim>git bisect bad</verbatim> until you find the problem.
+
+See also http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with
-bisect.txt
Tip: Sometimes you lose track of where you came from so before you use git-bisect go into the .git directory and make a copy of the HEAD file so you know where you started! You can then always go back by typing:
<verbatim>
git-reset --hard COPY_HEAD
</verbatim>
where COPY_HEAD is your copy of HEAD....
However check the contents of the HEAD file as sometimes it's just a reference such as <tt>ref: refs/head/master</tt> in which case make a copy of that file which is being pointed to.
+
+In theory you can do this also by typing:
+<verbatim>
+git checkout master
+</verbatim>
!Working with branches
A key feature of git is to maintain branches of code. For example you might keep Linus' code and your own in separate branches.