> As I understand things, we should, if we are working on a particular
> improvement, move ourselves onto a branch, make our changes, and then
> offer up the changes for some flavor of review, right?
I'm pretty new to git myself but am trying to use something like this
> Can someone explain to me how the final step is done? I have only
> this using org, where my changes were small enough that they could be
> eyeballed in patch files.
A Nikodemus suggested, I think sending a patch to the mailing list
would be the best thing for now.
(Once the repo is straightened out), I am going to add an unstable
branch into which patches will go first.
> But I have been working to get Marco's CLEAN-OP incorporated into
> and this involves adding files (notably in order to make tests). This
> puts me, I think, beyond the realm of easily reviewed patches. In
> case does one provide a branch in the common-lisp.net repo? Should
> create one's own public repository?
I agree with Nikodemus (again! <smile>)
> I have read some of the git tutorials but evidently I have not read
> right ones, since the answers to these questions still elude me.
I think that git is so flexible that knowing exactly what to do when
is elusive. We'll have to create a path by walking.
> I am very excited about the institution of the git repo, though, since
> the changes I am making, although they are modest (and most of the
> is another's), they do involve non-local changes, and really seem to
> exceed what one can comfortably do with CVS.
Yeah! Why don't you send the patch when you're ready and we can try to
make asdf:clean-op a test case.
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM * gwking on twitter