Clojure goes Git!
Rich Hickey
http://github.com/richhickey/clojure
http://github.com/richhickey/clojure-contrib
Issues and other development collaboration has moved to Assembla:
http://www.assembla.com/spaces/clojure
http://www.assembla.com/spaces/clojure-contrib
General discussions are going to stay right here on Google Groups:
http://groups.google.com/group/clojure
And there's a new group for Clojure developers and contributors:
http://groups.google.com/group/clojure-dev
non-contributors can follow along:
http://groups.google.com/group/clojure-dev/feeds
You can follow Clojure development on Twitter (exact content TBD):
http://twitter.com/clojuredev
Some items are still outstanding:
Importation of existing issues
Placement of generated contrib documentation
Patch submission policy
In particular, please don't send pull requests via GitHub at this
time.
The move to git was much requested, but accompanied by a certain
amount of apprehension from the non-git-savvy and some Windows users.
If you *are* git-savvy, please do your best to support others on the
group and irc as they get setup and find their bearings.
I'm looking forward to these new tools further enhancing the
collaboration amongst the Clojure community.
Thanks again to all for your participation!
Rich
Sean Devlin
On Jun 16, 8:17 pm, Rich Hickey <richhic...@gmail.com> wrote:
> Clojure and contrib repos are now on GitHub:
>
> Issues and other development collaboration has moved to Assembla:
>
Richard Newman
--
Sent from my iPhone.
Mark Volkmann
Clojure and contrib repos are now on GitHub:
http://github.com/richhickey/clojure
http://github.com/richhickey/clojure-contrib
In particular, please don't send pull requests via GitHub at this
time.
What's the reason to avoid "git pull"? Is there another way to get updates?
--
R. Mark Volkmann
Object Computing, Inc.
Antony Blakey
On 17/06/2009, at 10:29 AM, Mark Volkmann wrote:
> On Tue, Jun 16, 2009 at 7:17 PM, Rich Hickey <richh...@gmail.com>
> wrote:
>
> Clojure and contrib repos are now on GitHub:
>
> http://github.com/richhickey/clojure
> http://github.com/richhickey/clojure-contrib
>
> In particular, please don't send pull requests via GitHub at this
> time.
>
> What's the reason to avoid "git pull"? Is there another way to get
> updates?
To send a pull *request* in git is asking a remote repository to
accept *your* changes. It's how you contribute, it's not about
updating your copy of the repository.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
In anything at all, perfection is finally attained not when there is
no longer anything to add, but when there is no longer anything to
take away.
-- Antoine de Saint-Exupery
Mark Volkmann
To send a pull *request* in git is asking a remote repository to
On 17/06/2009, at 10:29 AM, Mark Volkmann wrote:
> On Tue, Jun 16, 2009 at 7:17 PM, Rich Hickey <richh...@gmail.com>
> wrote:
>
> Clojure and contrib repos are now on GitHub:
>
> http://github.com/richhickey/clojure
> http://github.com/richhickey/clojure-contrib
>
> In particular, please don't send pull requests via GitHub at this
> time.
>
> What's the reason to avoid "git pull"? Is there another way to get
> updates?
accept *your* changes. It's how you contribute, it's not about
updating your copy of the repository.
Antoni Batchelli
Git has a rather steep learning curve, but it pays to invest time on
it (or on any other distributed SCM).
For learning Git I found "Git Magic" ( http://www-cs-students.stanford.edu/~blynn/gitmagic/
) to be very helpful, and "Git Internals" ( https://peepcode.com/products/git-internals-pdf
) if you want to understand how it works internally.
Toni.
Antoni Batchelli
Mark Derricutt
If github land, this would involve Rich looking at his "fork queue" in the GUI and going "accept accept accept", or doing a command line "git pull".
--
Antony Blakey
On 17/06/2009, at 10:37 AM, Mark Volkmann wrote:
> I think you've got that backwards. A "git push" is how I would ask
> the remote repo to accept my changes. A "git pull" says I want to
> update my local repo with changes someone made in the remote repo.
No, you can send a *request* to Rich, via GitHub, to pull from your
repository. That's what a git pull *request* is - it's a request for
someone else to git pull. A 'git pull' is, as you say, the command to
pull commits into your repository and apply them, but that's not what
Rich is talking about here.
A common GitHub workflow is to fork someone's repository, clone your
fork, push your changes to your GitHub fork, and then send a pull
request to the owner of the 'canonical' repository that you forked
from, asking them to pull certain commits from your fork.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Human beings, who are almost unique in having the ability to learn
from the experience of others, are also remarkable for their apparent
disinclination to do so.
-- Douglas Adams
Antony Blakey
therefore recommend these:
http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git
http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github
https://peepcode.com/products/git
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Success is not the key to happiness. Happiness is the key to success.
-- Albert Schweitzer
Antony Blakey
On 17/06/2009, at 10:58 AM, Antony Blakey wrote:
> For anyone looking for explanatory material on git, I have, and can
> therefore recommend these:
>
> http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git
> http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github
> https://peepcode.com/products/git
And I forgot I had this: https://peepcode.com/products/git-internals-pdf
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
On the other side, you have the customer and/or user, and they tend to
do what we call "automating the pain." They say, "What is it we're
doing now? How would that look if we automated it?" Whereas, what the
design process should properly be is one of saying, "What are the
goals we're trying to accomplish and how can we get rid of all this
task crap?"
-- Alan Cooper
Richard Newman
Seconded. Worth the $9 to save the time spent trawling through bad
blog posts for similar info! As far as I can tell, this is also pretty
much the only resource to have if you want to do more than just "human-
oriented" version control using Git.
Antony Blakey
On 17/06/2009, at 10:58 AM, Antony Blakey wrote:
> http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github
BTW: the first episode of this is free, and includes a section called
'Send Pull Request'. It's purely about GitHub, rather than git itself.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Human beings, who are almost unique in having the ability to learn
Wrexsoul
> On 17/06/2009, at 10:58 AM, Antony Blakey wrote:
>
> >http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github
>
> BTW: the first episode of this is free
goes against the spirit of open source, wouldn't you say, if the docs
are all proprietary?
Richard Newman
>> blog posts for similar info! As far as I can tell, this is also
>> pretty
>> much the only resource to have if you want to do more than just
>> "human-
>> oriented" version control using Git.
>
> Are you two implying that there is no free documentation for git?
No. There is plenty of documentation for git -- the man pages are
good, and the Git docs[1] are also useful.
However, the Peepcode PDF, 121 pages of diagrams and clear text,
certainly beats the brief Git for Computer Scientists[2], and also
includes clear descriptions of typical workflow steps, installation,
etc. (not relevant in my case, but still useful to have in one place).
I'm happy to pay $9 for that.
> That goes against the spirit of open source, wouldn't you say, if
> the docs
> are all proprietary?
The docs produced by the Git project aren't proprietary: there are
plenty at [1], not to mention `man git`. I just see a great deal of
value in clear, explanatory text as produced by accomplished technical
writers. If the Peepcode PDF saves me five minutes, it was worth the
money.
I don't think a discussion of the spirit of open source is
particularly relevant to this forum, so I shan't address that point.
-R
[1] <http://git-scm.com/documentation>
[2] <http://eagain.net/articles/git-for-computer-scientists/>
Wrexsoul
> The docs produced by the Git project aren't proprietary: there are
> plenty at [1], not to mention `man git`. I just see a great deal of
> value in clear, explanatory text
open source software, not just free dense, hard-to-use manuals, if you
ask me. :)
Richard Newman
>
> http://github.com/richhickey/clojure
> http://github.com/richhickey/clojure-contrib
A big thumbs-up on this: I've already started extending the contrib
test suite (starting with clojure.set) in my own fork, which would be
a much more painful process for all parties without GitHub and git. I
guess this means that a DVCS does indeed encourage community
involvement!
(I'll continue to accrue patches in my repo until a patch submission
process arises.)
Tassilo Horn
Hi Antoni,
> For learning Git I found "Git Magic" ( http://www-cs-students.stanford.edu/~blynn/gitmagic/
> ) to be very helpful, and "Git Internals" ( https://peepcode.com/products/git-internals-pdf
> ) if you want to understand how it works internally.
I just want to add John Wiegley's excellent
Git from the bottom up [1]
to the list of must-reads for mastering git.
Bye,
Tassilo
__________
[1] http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
Rick Moynihan
This is awesome news, and something I'm really glad to see!
Cheers,
R.
Mark Volkmann
No, you can send a *request* to Rich, via GitHub, to pull from your
On 17/06/2009, at 10:37 AM, Mark Volkmann wrote:
> I think you've got that backwards. A "git push" is how I would ask
> the remote repo to accept my changes. A "git pull" says I want to
> update my local repo with changes someone made in the remote repo.
repository. That's what a git pull *request* is - it's a request for
someone else to git pull. A 'git pull' is, as you say, the command to
pull commits into your repository and apply them, but that's not what
Rich is talking about here.
A common GitHub workflow is to fork someone's repository, clone your
fork, push your changes to your GitHub fork, and then send a pull
request to the owner of the 'canonical' repository that you forked
from, asking them to pull certain commits from your fork.
git clone git://github.com/richhickey/clojure.git
After doing this, I still contend that the correct way to update my local repo is to cd to the directory of my local repo and run "git pull". Do you think that's wrong? It seems to me in this scenario the command we shouldn't use it "git push" because that would attempt push my changes back to the github repo.
Paul Stadig
Mark,
You are correct. The way that you should update *your* repository is to issue the "git pull" command within the working directory. Look at it from Rich's perspective. There are two ways that he can get changes from your repo into his repo. One is for you to cd into your directory and issue a "git push" command, but that assumes that you have access to write to his repo.
The other way is for him to cd into his directory and issue the "git pull" command. This only assumes that he has read access to your repo. There is a feature of GitHub (the website, not git itself) that is called a "pull request". You do not have write access to Rich's repo, but you want him to incorporate your changes, so you send him a "pull request". It is basically just an e-mail saying, "Hey, Rich, I have a cool new change that I'd like to see incorporated, cd into your working directory and issue a 'git pull'."
Rich has said to hold off on sending "pull requests" through the GitHub website. He is not saying that you cannot update your repo.
Paul
Christian Vest Hansen
you as a contributor. However, you can fork his repository on github,
clone it, and `git push` to that.
Indeed, when Rich has made changes to his repository and you want
those changes in your local repository, you do a `git pull`.
A "pull request" is a github workflow term for when you have a fork
(created with the "fork" button on github) with your own changes, and
you want Rich to pull in those changes. To do that, you press the
"pull request" button and Rich will get a private message, and
possibly also an email, with your request.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Meikel Brandmeyer
Am 17.06.2009 um 02:17 schrieb Rich Hickey:
> http://github.com/richhickey/clojure
> http://github.com/richhickey/clojure-contrib
For the mercurial users out there:
Both repos work with the latest hg-git
from http://hg-git.github.com! :)))
Sincerely
Meikel
stephaner
I like this introductory tutorial on git :
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
It doesn't show working with github, some tutorials are availables on
github site.
But it dit help me to get started.
Bye,
Stephane _/)
On Jun 17, 2:11 am, Tassilo Horn <tass...@member.fsf.org> wrote:
> > For learning Git I found "Git Magic" (http://www-cs-students.stanford.edu/~blynn/gitmagic/
> > ) to be very helpful, and "Git Internals" (https://peepcode.com/products/git-internals-pdf
Matt Clark
> For the mercurial users out there:
> Both repos work with the latest hg-git
> fromhttp://hg-git.github.com!:)))
have given both git (with github) and mercurial a decent try and I
found Hg to be a much more user friendly experience. This looks like
it should keep me happy.
- Matt
Konrad Hinsen
It didn't work for me this morning. I used hg-git to clone the
Clojure repository and then tried to build it. The build failed, and
further inspection showed that core.clj was a few hundred lines
shorter than the copy at github. I didn't pursue the issue any further.
I have used hg-git on various small repositories without problems,
but Clojure seems to be too much for it.
Konrad.
Mark Volkmann
Clojure and contrib repos are now on GitHub:
http://github.com/richhickey/clojure
http://github.com/richhickey/clojure-contrib
Jonas Bonér
On Jun 17, 2:17 am, Rich Hickey <richhic...@gmail.com> wrote:
> Clojure and contrib repos are now on GitHub:
>
> Issues and other development collaboration has moved to Assembla:
>
Meikel Brandmeyer
Am 17.06.2009 um 15:26 schrieb Konrad Hinsen:
> It didn't work for me this morning. I used hg-git to clone the
> Clojure repository and then tried to build it. The build failed, and
> further inspection showed that core.clj was a few hundred lines
> shorter than the copy at github. I didn't pursue the issue any
> further.
>
> I have used hg-git on various small repositories without problems,
> but Clojure seems to be too much for it.
hg-git put me in the lazy branch. I'm not sure how the
branches are handled by the hg-git module. I just
did "hg update -C origin/master" to get back to the
master and branch and everything worked for me.
(At least it compiled w/o problems, haven't had the
chance to check in detail.)
Sincerely
Meikel
Luke Renn
following post enough:
http://blog.mhartl.com/2008/10/14/setting-up-your-git-repositories-for-open-source-projects-at-github/
I use something similar to (barely) contribute to compojure. There
isn't anything like his 'edge' branch in compojure so it's a bit
simpler. I also branch for each fix or feature (he just creates a
single personal branch). It might seem complicated, but it ends up
being very clean and more closely matches the command line experience
imho (origin is the project, not your github fork).
Some things I'd recommend are never ever work on master (should always
fast forward), always branch for a feature or fix, and rebase that
branch before pushing it to github.
Sudish Joseph
git is the seeming obtuseness of the terminology and concepts. The
model itself is actually quite simple and everything becomes easier once
you get the basic concepts inside git (I think of it as repo = directed
graph of nodes and pointers into the graph & git = graph editor).
John Wiegley's doc does a great job of explaining that model, as he
says, from the bottom up.
-Sudish