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.
> 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
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.
> 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
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
> 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
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.
> 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
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/>
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.)
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
This is awesome news, and something I'm really glad to see!
Cheers,
R.
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.
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
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.
Clojure and contrib repos are now on GitHub:
http://github.com/richhickey/clojure
http://github.com/richhickey/clojure-contrib
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
John Wiegley's doc does a great job of explaining that model, as he
says, from the bottom up.
-Sudish