On 9 February 2011 04:16, Andreas Fuchs <asf@...> wrote:
> there. I hope a public discussion can weed them out and result in a
> situation that ensures steady development of SBCL.
Overall I like it. Two things.
1. A minor non-technical suggestion would be to change our commit
message policy to include a NEWS section:
frob the zorbnicator
news: "bug fix: zorbicator used to return wrong results when called
from foobar. lp#123456"
so that release manager can easily collate them (and when time permits
we can script NEWS generation) -- and more importantly, NEWS stops
being an endless source of merge conflicts. Currently it's a pain to
include NEWS in patches and branch items, as they're almost certain to
Just a thought -- I can certainly keep living with current NEWS policy.
2. My major question is... what about branch-version.lisp-expr? My
current magic makes it so that SBCLs built against my tree have
version numbers like
* "better-backtraces" is the name of the branch
* 7 is the number of commits on better-backtraces but not on master (i
keep only stuff from CVS on master)
*dirty tells me that there are uncommitted changes
A simple splice of branch-version.lisp-expr would not do this anymore, since in
the 10 should not be the number of commits since the last tag as per
git-describe, but the number of commits since last tag _before_ the
first commit on branch that is not on master. That is: 10 would be the
number of commits that were done on master before work on branch
My humble wish would be for this to be supported out of the box --
either by default, or by an option I can permanently toggle for my
PS. My branch-version.lisp-expr currently looks like this:
#.(flet ((git (command &rest args)
(sb-ext:run-program "/path/to/git" (cons command args)
(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")))))