history:
git://sbcl.boinkor.net/sbcl.git
-
+
and
git://repo.or.cz/sbcl.git
clones the SBCL Git mirror into the directory sbcl-git (there's a
naming convention in play here, but ignore that for now.) The clone
-contains full history, and is an independent repository on it's own
+contains full history, and is an independent repository on its own
right. Doing the clone takes as long as downloading 25Mb takes on your
line, but after that things are very fast.
nice in Git! The magic is: "git checkout -b hack-a-bit-more" -- but
leave that for another time.
-Let's do something. Edit version.lisp-expr, and maybe give SBCL some
-love.
+Let's do something. Edit BUGS, and maybe give SBCL some love.
git diff # shows you the changes in your tree
git status # shows you the state of files in the tree
Git has a notion of a separate "staging area", from which commits are
made. You can add content to the it by using git-add:
- git add version.lisp-expr
+ git add BUGS
git status
git diff
By default git-diff shows the differences between the working tree and
the staging area (which starts out identical to HEAD after a checkout).
-Edit version.lisp-expr again. Now you have three versions of it
-(ignoring all the historical versions for a second) to compare:
+Edit BUGS again. Now you have three versions of it (ignoring all the
+historical versions for a second) to compare:
git diff # between tree and staging area
git diff HEAD # between tree and last commit
We like our latest version, so do
- git add version.lisp-expr
+ git add BUGS
again. Now the latest version is in the staging area, and version that
used to be there is gone. You don't need to worry about the staging
can be used to compare two arbitrary versions. The -w switch tells Git
to ignore whitespace changes -- you can usually leave it out, but it's
-nice when diffing across the great whilespacification patches.
+nice when diffing across the great whitespacification patches.
Onwards: just so that we have a bit more history on the branch, edit
-version.lisp-expr again, and git-commit again. You can use
+BUGS again, and git-commit again. You can use
git commit -a
repository, and trickles changes back to upstream CVS manually --
from where they end up in sbcl.git. Turtles, you see." in the comment
box. Then you will be directed to set up an account, which you will
-then have to add as a "pusher" to your SBCL fork.
+then have to add as a "pusher" to your SBCL fork.
-Finally, add the following snipped (adjusting for your own name) in
+Finally, add the following snippet (adjusting for your own name) in
~/sbcl-git/.git/config
[remote "public"]
Since we're not (yet?) officially using Git, we want to get our
changes back into the CVS. git-cvsexport is the perfect tool for this.
-This assumes that you have a developer CVS checkout in ~/sbcl-cvs, and
-wish to commit the changes you have wrought on branch foo-hacks
+
+First, to make things a bit easier, we add a command of our own to
+Git, by adding the following to ~/sbcl-git/.git/config:
+
+ [alias]
+ sbcl-export = cvsexportcommit -w /home/yourname/sbcl-cvs -v
+
+This assumes that you have a developer CVS checkout in ~/sbcl-cvs.
+
+To commit the the changes you have wrought on branch foo-hacks
(compared to master):
+ # These three steps could be replaced by any other sequence that
+ # ends with all the changes you want to export to CVS at the top
+ # of the current branch (so that the final commit introduces all
+ # the changes.)
+ #
+ # In practice for small changes you may eg. just want to
+ #
+ # git checkout -b wip-fix-bug-xxx master
+ # ...fix bug on the branch...
+ # git commit -a
+ #
git checkout -b foo-hacks-to-cvs master
git merge --squash foo-hacks
- edit version.lisp-expr to be "CVS ready"
- git commit -a # edit the message to be "CVS ready"
- cd ~/sbcl-cvs
- GIT_DIR=~/sbcl-git/.git git cvsexportcommit -v foo-hacks-to-cvs
- review, fix any problems
- cvs commit -F .msg
+ git commit -a
-To make things a bit easier, add eg. this stanza to ~/sbcl-git/.git/config:
+ # This exports our stuff to the CVS tree. HEAD can be any <<commit id>>,
+ # so if you have a large number of commits on a branch that you want to
+ # commit to CVS one by one, you do that as well.
+ git sbcl-export HEAD
- [alias]
- sbcl-export = ! cd ~/sbcl-cvs && GIT_DIR=~/sbcl-git/.git git-cvsexportcommit -v
+ cd ../sbcl-cvs
-Then you can just run
+ Review, fix problems, etc. Edit version.lisp-expr, and add the
+ version number to .msg (which contains the commit message from Git.)
- git sbcl-export foo-hacks-to-cvs
-
-from inside ~/sbcl-git/, and have it prepare your CVS tree for commit.
+ cvs commit -F .msg
git-cvsexportcommit is fairly conservative by default, and will fail
if the patch doens't apply cleanly. If that happens, you can fix the
.msg -- holds the commit message
Finally, delete the foo-hacks-to-cvs branch after you've committed
-code to CVS. Of course, instead of using git-cvexportcommit you can
+code to CVS. Of course, instead of using git-cvsexportcommit you can
also manually make and apply patches, etc. For hairier cases it may
even be easier in the end:
0002-and-so-and-so-forth.patch
...
+Due to, among other things, the cvs->git synchronization lag it is
+easy to get conflicts on version.lisp-expr so generally speaking you
+never want to edit version-lisp.expr in Git, and only edit it (and add
+the version to the commit message) just when you are about to commit
+to CVS. It is, however, nice to have an idea how a given image came to
+be, which you can take care of by putting the following code in
+branch-version.lisp-expr:
+
+ #.(flet ((git (command &rest args)
+ (with-output-to-string (s)
+ ;; Adjust for your git installation location...
+ (sb-ext:run-program (merge-pathnames "bin/git" (user-homedir-pathname))
+ (cons command args) :output s))))
+ (format nil "~A.~A~@[-dirty~]"
+ (with-input-from-string (s (git "branch"))
+ (loop for line = (read-line s)
+ when (eql #\* (char line 0))
+ return (subseq line 2)))
+ (count #\newline (git "rev-list" "HEAD...master"))
+ (plusp (length (git "diff" "HEAD")))))
+
+which leads to your Git tree build to have version names like
+
+ 1.0.20.28.master.0-dirty
+
+ 1.0.20.28 on branch master, uncommitted changes
+
+ 1.0.20.19.wip-foo.4
+
+ 1.0.20.19 on branch wip-foo, 4 commits between current HEAD and
+ master, no uncommitted changes.
+
To get latest changes from the CVS Git mirror you originally cloned
from, do
on the branch you want to update on your private repository.
+Note that if you edit version.lisp-expr in the CVS tree and not before
+then the cvs commit command that git-cvsexportcommit prints does not
+list version.lisp-expr, so don't copy paste it.
+
This completes our whirlwind tour. I'm not saying this makes you
proficient in using Git, but at least you should be up and walking.
Reading
http://eagain.net/articles/git-for-computer-scientists/
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
-
+
and various Git manual pages is a good idea.
-One command I can in particular recommend getting familiar with is
-git-rebase. git-gui, git-citool, and gitk provide graphical interfaces
-for working with Git -- particularly gitk is an invaluable tool for
+Two commands I can in particular recommend getting familiar with are
+git-rebase and git-cherry-pick.
+
+git-gui, git-citool, and gitk provide graphical interfaces for
+working with Git -- particularly gitk is an invaluable tool for
visualizing history.
projects / sbcl.git / blobdiff