Differences between version 21 and revision by previous author of KernelDevelopmentWithGit.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 21 | Last edited on Thursday, November 1, 2007 6:16:14 am | by IanMcDonald | Revert |
| Older page: | version 15 | Last edited on Monday, July 17, 2006 12:22:11 pm | by AristotlePagaltzis | Revert |
@@ -4,9 +4,9 @@
<verbatim>
git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git mysourcedir
</verbatim>
-When people talk about pulling or rebasing, all it really means is transferring the appropriate objects over (usually by rsync)
. Provided you have created your own branch that is not a problem. It is not mentioned anywhere but because each change is given a unique number, provided that you have set up a branch (documented in <tt>howto</tt>), you can switch to a different [Git] to rsync off
and it works without losing your changes as most [Git]s are based around LinusTorvalds' [Git] tree and everbody
just freely exchanges objects (files) around the [Git] trees. I would advise you to commit your objects before rebasing, otherwise a <tt>git checkout -f</tt> will blow your changes away, as rebasing usually changes the branch back to master rather than your own.
+When people talk about pulling or rebasing, all it really means is transferring the appropriate objects over. Provided you have created your own branch that is not a problem. It is not mentioned anywhere but because each change is given a unique number, provided that you have set up a branch (documented in <tt>howto</tt>), you can switch to a different [Git] and it works without losing your changes as most [Git]s are based around LinusTorvalds' [Git] tree and everybody
just freely exchanges objects (files) around the [Git] trees. I would advise you to commit your objects before rebasing, otherwise a <tt>git checkout -f</tt> will blow your changes away, as rebasing usually changes the branch back to master rather than your own.
David Miller says this about pulling out patches:
> If you keep your <tt>.git/ORIG_HEAD</tt> sane, you can use a script like the following to pull your local changes out of a tree one-by-one. It drops them into a directory called <tt>patches/</tt> at the top-level and names them <tt>1.diff</tt>, <tt>2.diff</tt>, <tt>3.diff</tt>, etc. with changelogs prepended to the beginning. I call it <tt>git-mkpatches</tt>.
@@ -48,20 +48,16 @@
git pull
git-reset
</verbatim>
-The only exception to this is that it only pulls from the master tree. If you want to pull older tags do the following:
-> <verbatim>
-> cd my-tree
-> rsync -luvaz --progress rsync://rsync
.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.14.git/* .git/
-> </verbatim>
+The only exception to this is that it only pulls from the master tree. If you want to pull older tags you will need to issue other commands
.
If you want to then work on an older version then do the following for example if you want to work on 2.6.14:
<verbatim>
git-reset --hard v2.6.14
</verbatim>
-Sometimes after doing a rsync or
a git-pull you can have fatal merge errors. The best way to resolve this is often to type git-reset.
+Sometimes after doing a git-pull you can have fatal merge errors. The best way to resolve this is often to type git-reset.
If you get funny kernel version numbers when using [Git] it is a "feature" that can be turned off by unsetting CONFIG_LOCAL_VERSION. If you are in the menuconfig you can do this by going to General setup-->Automatically append version information to the version string.
Most [LinuxKernel] related [Git]s can be found at http://www.kernel.org/git/ which is where you should pull/rebase from if you are doing serious KernelDevelopment.
@@ -70,32 +66,47 @@
<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:
-<verbatim>
-URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
-Pull: master:origin
-</verbatim>
-
-The above format is the default but it is better if you use the git protocol (not supported on all servers) as per below as it is more efficient than rsync and much more efficient than [HTML] which sends everything in a big lump.
<verbatim>
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Pull: master:origin
</verbatim>
-!Using git-bisect
+In git version 1.5 the above has changed and the file is now in .git/config. There is also a new command git-remote for managing multiple remote repositories.
+
+
!Using git bisect
+
+To use git bisect go to the bad code first (normally where you are at) and then type <tt>git bisect start</tt> and then <tt>git bisect bad</tt>
+
+Now go to a place that is good by checking out code something like <tt>git-reset --hard v2.6.19-rc6</tt>. If that proves to be good then do <tt>git bisect good</tt> and then do each change marking good or bad with <tt>git bisect good</tt> or <tt>git bisect bad</tt> 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.
+
+You can do this also by typing:
+<verbatim>
+git bisect reset master
+git reset --hard FETCH_HEAD
+</verbatim>
+providing you want to go back to the last time you synced up.
!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.
@@ -119,7 +130,32 @@
There is a tool to help manage a series of patches called [Stacked Git | http://www.procode.org/stgit/] or stgit for short. The [Debian] [Package] is called <tt>stgit</tt>.
Basically you create a branch (see above) and then manage stacks of patches in this and resync upstream when you want to.
+
+!Mailing patches. ArnaldoMelo says
+<verbatim>
+I use mutt for everything now, did it for years, then tried to use
+thunderbird, evolution, kmail, you name it, ran away screaming back to
+good old mutt + vi.
+
+For sending patches I'll use git-send-email in the next DCCP batch, the
+way it uses reply-to to chain patch series is awesome, and it'll save
+lotsa time by being able to use it together with 'git-format-patch -n
+origin', so, in summary what I do is:
+
+1. git-clone --reference linus-2.6 davem-2.6 acme-2.6
+2. hack away (these days, mostly merge like a turtle :-P)
+3. GIT_AUTHOR_NAME="Gerrit" GIT_AUTHOR_EMAIL="gerrit@..." git-commit -a -s
+4. git-format-patch -n origin
+5. write 0000-patch-series.txt describing the patche series
+6. push to master.kernel.org (that will be propagated to
+ www.kernel.org/git, etc)
+7. git-send-email with 0000-patch-series.txt and what was produced in
+ step #4
+8. rm -rf acme-2.6
+9. hiatus, that thing called Real Work does a blunt, real time preempt
+10. goto #1
+</verbatim>
----
Part of CategoryKernel
