git-scm.com

Hey all,

A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com.  I had meant
to discuss this with Petr before posting it to you all, but I
published a blog post that got a bit more attention than I expected,
and I didn't want you all to think I didn't care about your opinion,
as some have already accused me of.

Anyhow, I'm discussing with Petr about where we want to go from here -
what changes he'd like to make, etc, but I obviously value your
opinion as well, so please let me know what you think.  The content
has barely changed, it's really just a usability overhaul.  I want to
make sure that whatever someone is looking for (especially someone
new), they can find in a few clicks and a few seconds.

Next, I will be working on the larger end-user documentation project,
which will linked to from the documentation page of this site, and
probably the main page too.  I'll keep this list updated as I go,
since people tend to think I don't care about the community when I try
not to waste your time. :)

Scott

On Fri, Jul 25, 2008 at 19:35, Scott Chacon [off-list ref] wrote:

A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com.  I had meant
to discuss this with Petr before posting it to you all, but I
published a blog post that got a bit more attention than I expected,
and I didn't want you all to think I didn't care about your opinion,
as some have already accused me of.

I had a looksie at the site and I think the documentation section [0]
could use some TLC. It might be because it's getting late, but there's
not really any 'eye catchers', no "CLICK ME!" link for someone
browsing around looking for Documentation. In order to find what you
want you have to read -a lot- of the page, which I think is a sign
that the page would do well with some TLC ;).
Now I'll admit that the git.or.cz version [1] is a lot worse, but with
this being an attempt to make it a lot more newbie friendly...

[0] http://git-scm.com/documentation
[1] http://git.or.cz/gitwiki/GitDocumentation

PS: I think you forgot the </shameless plug> when you did put up your
own e-book in the books section but did not put "Git Magic" there ;).

-- 
Cheers,

Sverre Rabbelier

On Friday 25 July 2008, Scott Chacon wrote:

Hey all,

A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com.  I had meant
to discuss this with Petr before posting it to you all, but I
published a blog post that got a bit more attention than I expected,
and I didn't want you all to think I didn't care about your opinion,
as some have already accused me of.

Anyhow, I'm discussing with Petr about where we want to go from here -
what changes he'd like to make, etc, but I obviously value your
opinion as well, so please let me know what you think.  The content
has barely changed, it's really just a usability overhaul.  I want to
make sure that whatever someone is looking for (especially someone
new), they can find in a few clicks and a few seconds.

Thanks for the update. Looks good.

Minor niggle: On the download page, in the Binaries table, Cygwin is listed 
before msysGit. I'm under the impression that msysGit is what we really 
want to be pushing on Windows (it's faster, smaller, and less strange to 
Windows-people (i.e. less Unix-y)), so you might want to switch the order 
around.


Have fun!

...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

I mean to have the new documentation I'm beginning be the
'eye-catcher' on that page eventually.  Not because it's done by me,
but because it will be open and I want to encourage people to
contribute to it (we must make it perfect, after all) :)  However, the
big thing is that I couldn't think of a _single_ resource that I would
want to point people at.  I tried to split everything up
categorically, but I don't know what you're looking for being there
exactly.  Thanks for the feedback, though, I'll see what I can do.

As for my own plug, I feel kinda bad about that, but I have gotten a
lot of feedback that it's a useful resource and I thought by
separating it out into a 'books' section, I had cleanly distinguished
between the corporate sellouts and everyone else :)  I have Git Magic
in the Tutorials section, including a nice plug for it and a link to
it's source on Github - if it were an e-book (had a pdf version and a
cover) I would happily put it over there.  I would like, however, to
keep the downloadable resources seperate from the free online
resources (though now that I think about it, I should probably put
"Git from the Bottom Up" pdf up there somewhere...).  I want people to
know they have to shell out money for those greedy bastards projects,
though.  There will be an O'Reilly book soon, and I'll put that up,
too. If you have other resources that you think are really good, let
me know so I can add them.

Scott

On Fri, Jul 25, 2008 at 2:20 PM, Sverre Rabbelier [off-list ref] wrote:

On Fri, Jul 25, 2008 at 19:35, Scott Chacon [off-list ref] wrote:

quoted

A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com.  I had meant
to discuss this with Petr before posting it to you all, but I
published a blog post that got a bit more attention than I expected,
and I didn't want you all to think I didn't care about your opinion,
as some have already accused me of.

I had a looksie at the site and I think the documentation section [0]
could use some TLC. It might be because it's getting late, but there's
not really any 'eye catchers', no "CLICK ME!" link for someone
browsing around looking for Documentation. In order to find what you
want you have to read -a lot- of the page, which I think is a sign
that the page would do well with some TLC ;).
Now I'll admit that the git.or.cz version [1] is a lot worse, but with
this being an attempt to make it a lot more newbie friendly...

[0] http://git-scm.com/documentation
[1] http://git.or.cz/gitwiki/GitDocumentation

PS: I think you forgot the </shameless plug> when you did put up your
own e-book in the books section but did not put "Git Magic" there ;).

--
Cheers,

Sverre Rabbelier

Actually, that's directly from git.or.cz - I thought about removing
the Cygwin one, but perhaps swapping the order would be better.  Any
thoughts?

Scott

On Fri, Jul 25, 2008 at 2:36 PM, Johan Herland [off-list ref] wrote:

On Friday 25 July 2008, Scott Chacon wrote:

quoted

Hey all,

Thanks for the update. Looks good.

Minor niggle: On the download page, in the Binaries table, Cygwin is listed
before msysGit. I'm under the impression that msysGit is what we really
want to be pushing on Windows (it's faster, smaller, and less strange to
Windows-people (i.e. less Unix-y)), so you might want to switch the order
around.


Have fun!

...Johan

--
Johan Herland, [off-list ref]
www.herland.net

Hi,

Just a very short note: I like it ;-)
Amusing picture.

You perhaps should switch the page encoding to utf-8, since many
names of contributors are broken without.
I've just taken a view at the XHTML. You have:
	<?xml version="1.0" encoding="iso-8859-1" ?>
But:
	<meta http-equiv="content-type" content="text/html; charset=UTF-8" />

And the HTTP server does not set an encoding, as it seems, which is ok.
So please change the first line to
	<?xml version="1.0" encoding="UTF-8"?>

Thanks,
  Stephan

-- 
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F

Thanks - we're working on validating the pages now.  This should be
fixed shortly.

Scott

On Fri, Jul 25, 2008 at 3:02 PM, Stephan Beyer [off-list ref] wrote:

Hi,

Just a very short note: I like it ;-)
Amusing picture.

You perhaps should switch the page encoding to utf-8, since many
names of contributors are broken without.
I've just taken a view at the XHTML. You have:
       <?xml version="1.0" encoding="iso-8859-1" ?>
But:
       <meta http-equiv="content-type" content="text/html; charset=UTF-8" />

And the HTTP server does not set an encoding, as it seems, which is ok.
So please change the first line to
       <?xml version="1.0" encoding="UTF-8"?>

Thanks,
 Stephan

--
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F

Looks fine but this page looks like a big advertising for Github with
five links on the middle of the front page + one big logo at the
bottom.

  Hi,

On Fri, Jul 25, 2008 at 10:35:43AM -0700, Scott Chacon wrote:

Anyhow, I'm discussing with Petr about where we want to go from here -
what changes he'd like to make, etc, but I obviously value your
opinion as well, so please let me know what you think.  The content
has barely changed, it's really just a usability overhaul.  I want to
make sure that whatever someone is looking for (especially someone
new), they can find in a few clicks and a few seconds.

  when the initial NIH reaction passes, I have to admit that I do rather
like it - and it's not only because you keep mentioning how awesome I am
in your blog post. ;-)

  I wonder if all the Git users find the heading rather funny as I did,
instead of unprofessional - but maybe we don't care about users without
a particular sense of humor. I'm also not overly fond of the color theme
but I'm perhaps just too heavy of a blue fan.

  Plenty of minor fixes are available for pull at

	git://github.com/pasky/learn-github.git
	(http://github.com/pasky/learn-github/tree/master)

(Note that I didn't test whether the pages still look ok with my changes
since I have no Ruby on Rails setup; hopefully they should, though.)

  Other non-trivial nits:

  * I'm feeling a bit uneasy about listing so many projects using Git;
I haven't heard about quite a few of these and I'm not sure on what
merit should we list projects. "Prototype" or "Liftweb" and probably
even "Rubinius", is that going to ring a bell for major part of visitors
so that they say "oh, even _those_ guys are using Git"?

  * Cut the contributors list at 4 or 5 commits? Below that, the list
is getting fairly useless anyway and you have trouble with keeping the
names reasonably well-formed.

  * Reusing captions from command manpages in the Documentation page
shows nicely how awful they sometimes are. :-) This is probably something
to fix upstream, though.

  * Is "Git for the lazy" really unique in some regard to deserve to be
listed among the other resources? I think we should minimalize
redundancy at the documentation page, the amount of material is already
overwhelming and it should be obvious for the visitor which document to
choose based on his needs. I have similar doubts about the 37signals
resources.

	In other words, "let's keep the resources orthogonal!"

  * There is no reference to the Wiki in the documentation, only to the
[GitDocumentation] page; I think there should be a reference to the
[GitFaq] page too - a lot of important points that are not obvious
to newcomers are covered there. I'm just not sure where exactly to put
the link.

  * I would go as far as put the link to the Wiki itself to the
navigation bar, simply since it is such a crucial resource.

  * A guide on maintaining third-party patches is currently missing.

  * The development page is not referenced anywhere; the missing
information are mailing list details (how to subscribe) and a link to
SubmittingPatches. Also, I have recently talked with Junio about adding
a link to the Note from the Maintainer, but we didn't yet figure out
where to stabilize the location of that page.

Next, I will be working on the larger end-user documentation project,
which will linked to from the documentation page of this site, and
probably the main page too.  I'll keep this list updated as I go,
since people tend to think I don't care about the community when I try
not to waste your time. :)

  How does that compare with the Git user manual? Have you considered
collaborating on that one, or what are your reasons not to? Or are you
trying to do something different?

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie

  Hi,

  oops, so I decided to unbundle this question from the previous post,
but forgot to modify the subject line...

  When the git-scm.com site gets refined a bit further, it might make a
lot of sense to make http://git.or.cz/index.html a redirect to
http://git-scm.com/ and thus delegate the new site to the official Git
homepage. Of course, I would be transferring the control of the homepage
from my hands so I would like to poll the community about how do people
feel about this - opinion of core Git contributors would be especially
welcome; I find myself rather happy with the new site, so I will
implicitly take silence as an agreement.

  Here is a breakdown of possible pros and cons that come on my mind:

  + The new site has much nicer and more catchy design.
  + The new site seems to have a lot of potential to grow to a rather
comprehensive resource.
  + The new site would probably have much more active maintainer. ;-)

  - The new site is affiliated with a commercial entity - GitHub.
The website maintainer also has commercial interest in some published
Git learning materials, which might generate certain conflict of
interests; we must trust them that they handle this well.
  - Both GitHub and Scott seem to be rather distanced from the "core"
Git development community. This might or might not be an issue.
  - The new site is implemented in much more complicated way than the
old one, having a full-fledged Ruby on Rails machinery behind it and
linking to bunch of obfuscated JavaScript code; I don't think it's that
big a deal, though.

  The negatives section writeup is longer, but in fact I think the
positives win here; I also have a bit of bad conscience about not giving
git.or.cz the amount of time it would deserve...

  P.S.: To simplify matters, I talk only about index.html, but of course
it would make sense to transfer both the SVN Crash Course _AND_ the Git
Wiki along; we might keep the Cogito homepage for purely historical
interest too, I don't know.

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie

Hi,

On Fri, 25 Jul 2008, Scott Chacon wrote:

A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com.

I do not like the implication that Git eats trees.

I also do not like that the link to "Documentation" looks more like a 
too-short cheat-sheet.

I had meant to discuss this with Petr before posting it to you all, but 
I published a blog post that got a bit more attention than I expected, 
and I didn't want you all to think I didn't care about your opinion, as 
some have already accused me of.

My first reaction was: he could have given Pasky a little more time to 
react.

But then, I think that git.or.cz looks more professional (read: more 
respectful, less geekish), so I think there is not much harm in that.

Ciao,
Dscho

5 links in the middle?  You mean to the project links?  I just choose
the biggest, most well known projects I could think of and stuck them
up there - many of them are at GitHub.  If you have a list you like
better, I would be happy to add them, or discuss the final list, but I
hardly think that's an advertisement for GitHub.  As for the link in
the footer, that's where I'm hosting my repo for the page, and it's at
the bottom of the page and tiny.

I am more concerned about the logo at the bottom, and Petr and I are
discussing this - I can remove the logo, but then I'd have to pay for
this out of my pocket instead of having a small logo on the page.
It's not bad to host a few webpages, but this will eventually have
diagrams and screencasts and whatever else I can do for comprehensive
documentation, which can add up in brandwidth costs (especially the
screencasts).  The Githubbers have offered to pay for that and host
media and whatnot for the project, backed by a real team of sysadmins.
 That seems like a pretty good deal for a small logo at the bottom of
the page.  For newbies, that is likely even a good thing - makes them
see that there is some corporate interest in it - that it's not just
an obscure tool for the hard core.

I am open to discussion on that, but I can't change where Ruby on
Rails has decided to host their repo.

Scott

On Fri, Jul 25, 2008 at 6:38 PM, Patrick Aljord [off-list ref] wrote:

Looks fine but this page looks like a big advertising for Github with
five links on the middle of the front page + one big logo at the
bottom.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  Hi,

On Sat, Jul 26, 2008 at 04:25:16AM +0200, Johannes Schindelin wrote:

On Fri, 25 Jul 2008, Scott Chacon wrote:

quoted

A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com.

I do not like the implication that Git eats trees.

  yes, I keep wondering about the logo as well. On one side it is rather
amusing, on the other side... somehow it didn't win my heart over and it
*does* look somewhat unprofessional.

I also do not like that the link to "Documentation" looks more like a 
too-short cheat-sheet.

  I personally don't find the idea of having direct links to the most
used commands bad, though I'm not sure how useful will it be in
practice.

But then, I think that git.or.cz looks more professional (read: more 
respectful, less geekish), so I think there is not much harm in that.

  Note that I tried to fix up a lot of bits that I felt were a little
too colloquial in my patch series I linked in a previous mail.

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie

  Hi,

On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:

I am more concerned about the logo at the bottom, and Petr and I are
discussing this - I can remove the logo, but then I'd have to pay for
this out of my pocket instead of having a small logo on the page.

  I actually think that this is *one* reference to GitHub that is
perfectly and 100% okay; if it is sponsoring the hosting, it deserves
the logo, and it is fairly non-intrusive. I _am_ watching out warily
for excessive GitHub references within the rest of the site - if only
because I have kind of personal interest in a competitor of GitHub and
thus don't want GitHub to get unwarranted free advertising. :-)

				Petr "Pasky" Baudis

Hi,

On Fri, 25 Jul 2008, Scott Chacon wrote:

5 links in the middle?

What 5 links in the middle?

*scrolls down*

Ah, the top-posting syndrome.

Old quote, but more valid than ever:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

I find it almost comical that people do not realize how unnaturally they 
behave, and how hard they make it on their recipients, when they top-post.

Oh, and usually, I take top-posting as a clear sign that the poster is not 
worth replying to.  Take this mail as a sign that I take care of what you 
said, _in spite of_ your top-posting.

Ciao,
Dscho

On Sat, 26 Jul 2008, Petr Baudis wrote:

 Hi,

On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:

quoted

I am more concerned about the logo at the bottom, and Petr and I are
discussing this - I can remove the logo, but then I'd have to pay for
this out of my pocket instead of having a small logo on the page.

 I actually think that this is *one* reference to GitHub that is
perfectly and 100% okay; if it is sponsoring the hosting, it deserves
the logo, and it is fairly non-intrusive. I _am_ watching out warily
for excessive GitHub references within the rest of the site - if only
because I have kind of personal interest in a competitor of GitHub and
thus don't want GitHub to get unwarranted free advertising. :-)

				Petr "Pasky" Baudis

since this is a Ruby on Rails site, could the 'five links' that have been 
bothering people be randomly selected? if every time you go to the site 
you get a different list of projects it show how broadly git is used. it's 
not as 'in your face' as managing to select five that cause people to say 
"wow, they're using this", but different people will react to different 
sites.

if this table gets populated by GitHub, kernel.org, and a couple other 
sources it should be vendor independant enough (and we need a table like 
this anyway for the 'list of projects that use git', so it serves two 
purposes)

David Lang

Johannes Schindelin wrote:

I do not like the implication that Git eats trees.

Eridius said on IRC:
 "it's a Git", "he's a Blob that's Committed to storing Trees"


I still like the picture, though it can hurt environmentalists.

Regards,
  Stephan

-- 
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F

Hi,

On Sat, 26 Jul 2008, Stephan Beyer wrote:

Johannes Schindelin wrote:

quoted

I do not like the implication that Git eats trees.

I still like the picture, though it can hurt environmentalists.

It's not just environmentalists.  If I put myself in the shoes of a Git 
newbie, I would get the impression that Git eats my trees, i.e. destroys 
them.

Very good first impression.

Not,
Dscho

On Fri, Jul 25, 2008 at 8:07 PM, Johannes Schindelin
[off-list ref] wrote:

Hi,

On Sat, 26 Jul 2008, Stephan Beyer wrote:

quoted

Johannes Schindelin wrote:

quoted

I do not like the implication that Git eats trees.

I still like the picture, though it can hurt environmentalists.

It's not just environmentalists.  If I put myself in the shoes of a Git
newbie, I would get the impression that Git eats my trees, i.e. destroys
them.

Very good first impression.

Not,
Dscho

I was a bit concerned about using the little guy too, but I've gotten
overall very good feedback about him - people seem to like him.  I
think it's good to have a little bit of illustration on a page.
However, as for your concerns, I think a) it's really hard to argue
that environmentalists would actually care what that thing is doing
and b) a newbie to Git will have no idea what a 'tree' is - that is
really only a sort of inside joke.  You would have to have been using
git for a good amount of time to know that 'eating a tree' would be a
bad thing.  That's why I've been telling people that he's _storing_
trees and that you don't want to be around when he 'gc --prune's :)

Scott "not top-posting" Chacon

On Fri, Jul 25, 2008 at 7:47 PM,  [off-list ref] wrote:

On Sat, 26 Jul 2008, Petr Baudis wrote:

quoted

 Hi,

On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:

quoted

I am more concerned about the logo at the bottom, and Petr and I are
discussing this - I can remove the logo, but then I'd have to pay for
this out of my pocket instead of having a small logo on the page.

 I actually think that this is *one* reference to GitHub that is
perfectly and 100% okay; if it is sponsoring the hosting, it deserves
the logo, and it is fairly non-intrusive. I _am_ watching out warily
for excessive GitHub references within the rest of the site - if only
because I have kind of personal interest in a competitor of GitHub and
thus don't want GitHub to get unwarranted free advertising. :-)

                               Petr "Pasky" Baudis

since this is a Ruby on Rails site, could the 'five links' that have been
bothering people be randomly selected? if every time you go to the site you
get a different list of projects it show how broadly git is used. it's not
as 'in your face' as managing to select five that cause people to say "wow,
they're using this", but different people will react to different sites.

if this table gets populated by GitHub, kernel.org, and a couple other
sources it should be vendor independant enough (and we need a table like
this anyway for the 'list of projects that use git', so it serves two
purposes)

David Lang

I would really like to have the big ones there all the time ('Linux',
'Ruby on Rails', 'WINE', 'X.org', etc)  Prototype and MooTools are
pretty big in the web dev world, which a lot of people are starting to
come from - at least Prototype should be there all the time.  For the
rest, if we want to pool a bunch of other projects from different
places, that would be cool, but they should be active - I don't want
people clicking on something above the fold and getting a dead
project.  If someone wants to help me vet a list, I'd be happy to do
that.

However, that being said, it's going to be difficult to have Github
projects not dominate the list a bit.  The fact is that it hosts far,
far more projects than any other single hosting service.  Just in
fully public projects, the current stats (from the website pages) are
something like this:

kernel.org : 475
repo.or.cz : 1,553
gitorious   : 780
github       : 10,560

It hosts far more than that if you include private projects, too.  So,
if we want to choose totally randomly, it's going to be at least a 5:1
ratio between github projects and all other public hosting providers.
If anything, statistically, the current list is conservative in it's
links to github projects.  For me to avoid using them is artificially
punishing them for having paid plans, which is silly.

Scott

How about linking to the project web page or the official blog where
the move was announced when available? I think that's how it's done on
the mercurial page. And it explains people why the switch was done
rather then linking to a source repository they might not care about
and the link to the project page might give a hint about the
importance of the given project for those that might not know it (such
as prototype, mootools or liftweb).

example:
http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git

On Fri, 25 Jul 2008, Scott Chacon wrote:

On Fri, Jul 25, 2008 at 7:47 PM,  [off-list ref] wrote:

quoted

On Sat, 26 Jul 2008, Petr Baudis wrote:

quoted

 Hi,

On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:

quoted

I am more concerned about the logo at the bottom, and Petr and I are
discussing this - I can remove the logo, but then I'd have to pay for
this out of my pocket instead of having a small logo on the page.

 I actually think that this is *one* reference to GitHub that is
perfectly and 100% okay; if it is sponsoring the hosting, it deserves
the logo, and it is fairly non-intrusive. I _am_ watching out warily
for excessive GitHub references within the rest of the site - if only
because I have kind of personal interest in a competitor of GitHub and
thus don't want GitHub to get unwarranted free advertising. :-)

                               Petr "Pasky" Baudis

since this is a Ruby on Rails site, could the 'five links' that have been
bothering people be randomly selected? if every time you go to the site you
get a different list of projects it show how broadly git is used. it's not
as 'in your face' as managing to select five that cause people to say "wow,
they're using this", but different people will react to different sites.

if this table gets populated by GitHub, kernel.org, and a couple other
sources it should be vendor independant enough (and we need a table like
this anyway for the 'list of projects that use git', so it serves two
purposes)

David Lang

I would really like to have the big ones there all the time ('Linux',
'Ruby on Rails', 'WINE', 'X.org', etc)  Prototype and MooTools are
pretty big in the web dev world, which a lot of people are starting to
come from - at least Prototype should be there all the time.  For the
rest, if we want to pool a bunch of other projects from different
places, that would be cool, but they should be active - I don't want
people clicking on something above the fold and getting a dead
project.  If someone wants to help me vet a list, I'd be happy to do
that.

I can see things going either way on this, and I'm sure that the algorithm 
for the 'best' way to select projects can be tweaked endlessly. I am not 
that afraid of someone hitting a dead link, especially if you were to list 
them as 'projects 2,4895,9287,104,18439 of xxxxxx project that have 
reported using git' with numbers that large people expect that some 
projects will have gone dead, and even if they are all live today, how 
frequently did you plan to re-check them to decide they are dead? (and 
what is your definition of dead?)

However, that being said, it's going to be difficult to have Github
projects not dominate the list a bit.  The fact is that it hosts far,
far more projects than any other single hosting service.  Just in
fully public projects, the current stats (from the website pages) are
something like this:

kernel.org : 475
repo.or.cz : 1,553
gitorious   : 780
github       : 10,560

It hosts far more than that if you include private projects, too.  So,
if we want to choose totally randomly, it's going to be at least a 5:1
ratio between github projects and all other public hosting providers.
If anything, statistically, the current list is conservative in it's
links to github projects.  For me to avoid using them is artificially
punishing them for having paid plans, which is silly.

as long as there is a mechanism to add things to the list I don't see 
anything wrong with the frequency reflecting this reality. anyone who 
thinks the numbers are skewed is free to add other projects to the list.

part of this is reducing the room for people to accuse you of impropriaty, 
if you select the links people can accuse you of playing favorites, if 
it's random selection and includes competitors entire lists, it's much 
clearer that you aren't skewing things.

David Lang

On Fri, Jul 25, 2008 at 6:53 PM, Petr Baudis [off-list ref] wrote:

 Hi,

On Fri, Jul 25, 2008 at 10:35:43AM -0700, Scott Chacon wrote:

quoted

Anyhow, I'm discussing with Petr about where we want to go from here -
what changes he'd like to make, etc, but I obviously value your
opinion as well, so please let me know what you think.  The content
has barely changed, it's really just a usability overhaul.  I want to
make sure that whatever someone is looking for (especially someone
new), they can find in a few clicks and a few seconds.

 when the initial NIH reaction passes, I have to admit that I do rather
like it - and it's not only because you keep mentioning how awesome I am
in your blog post. ;-)

 I wonder if all the Git users find the heading rather funny as I did,
instead of unprofessional - but maybe we don't care about users without
a particular sense of humor. I'm also not overly fond of the color theme
but I'm perhaps just too heavy of a blue fan.

 Plenty of minor fixes are available for pull at

       git://github.com/pasky/learn-github.git
       (http://github.com/pasky/learn-github/tree/master)

I've pulled in all this stuff and it should be live now.

 Other non-trivial nits:

 * I'm feeling a bit uneasy about listing so many projects using Git;
I haven't heard about quite a few of these and I'm not sure on what
merit should we list projects. "Prototype" or "Liftweb" and probably
even "Rubinius", is that going to ring a bell for major part of visitors
so that they say "oh, even _those_ guys are using Git"?

Based on a conversation in the other thread, I think we should have a
list that is suggested by the community and just have the 3 or 4 that
are really famous (Git, Linux, RoR...) and have the rest randomly
pulled from that list - changed every day or so.

 * Cut the contributors list at 4 or 5 commits? Below that, the list
is getting fairly useless anyway and you have trouble with keeping the
names reasonably well-formed.

Done and pushed.

 * Reusing captions from command manpages in the Documentation page
shows nicely how awful they sometimes are. :-) This is probably something
to fix upstream, though.

I saw you changed some of these, I can take another pass.  I'm not
entirely sure how useful it is to have the commands on that page, to
tell the truth.  This may go away as the documentation page evolves.

 * Is "Git for the lazy" really unique in some regard to deserve to be
listed among the other resources? I think we should minimalize
redundancy at the documentation page, the amount of material is already
overwhelming and it should be obvious for the visitor which document to
choose based on his needs. I have similar doubts about the 37signals
resources.

       In other words, "let's keep the resources orthogonal!"

I agree - I would like to pull a lot of the information in those links
into one open-source book that is kept up by the community and hosted
at this page.  The documentation page will change significantly as we
try to simplify and maximize the usefulness of the page.

 * There is no reference to the Wiki in the documentation, only to the
[GitDocumentation] page; I think there should be a reference to the
[GitFaq] page too - a lot of important points that are not obvious
to newcomers are covered there. I'm just not sure where exactly to put
the link.

 * I would go as far as put the link to the Wiki itself to the
navigation bar, simply since it is such a crucial resource.

Perhaps I should just do this - would that cover the previous one as well?

 * A guide on maintaining third-party patches is currently missing.

 * The development page is not referenced anywhere; the missing
information are mailing list details (how to subscribe) and a link to
SubmittingPatches. Also, I have recently talked with Junio about adding
a link to the Note from the Maintainer, but we didn't yet figure out
where to stabilize the location of that page.

I would be happy to put the note somewhere, and I will work on getting
the other few pages from the original site put up and linked
somewhere.

 How does that compare with the Git user manual? Have you considered
collaborating on that one, or what are your reasons not to? Or are you
trying to do something different?

I would like to - I have personally found that invaluable in learning
Git, but I would like it to be more digestible and I would like to add
a lot of supporting media to it - screencasts and diagrams, to help
people that are more visual learners. Loading up a document where the
TOC is several pages long is intimidating and difficult to start and
stop with.

Scott

On Sat, Jul 26, 2008 at 4:55 PM, Scott Chacon [off-list ref] wrote:

I was a bit concerned about using the little guy too, but I've gotten
overall very good feedback about him - people seem to like him.  I
think it's good to have a little bit of illustration on a page.

It's clearly an inside joke, but I like it. And let's have the
environmentalists-with-a-sense-of-humour with us. The others can use
something else :-)



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

"Scott Chacon" [off-list ref] writes:

A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com.  I had meant
to discuss this with Petr before posting it to you all, but I
published a blog post that got a bit more attention than I expected,
and I didn't want you all to think I didn't care about your opinion,
as some have already accused me of.

On thing I am curious about: how do you plan to have current version
of Git in the download / last version section?  Petr Baudis uses
custom script, which search git mailing list for "[ANNOUNCE]" posts,
and automatically updates download / last version links.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

On Sat, Jul 26, 2008 at 01:03:26AM -0700, Jakub Narebski wrote:

"Scott Chacon" [off-list ref] writes:

quoted

A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com.  I had meant
to discuss this with Petr before posting it to you all, but I
published a blog post that got a bit more attention than I expected,
and I didn't want you all to think I didn't care about your opinion,
as some have already accused me of.

On thing I am curious about: how do you plan to have current version
of Git in the download / last version section?  Petr Baudis uses
custom script, which search git mailing list for "[ANNOUNCE]" posts,
and automatically updates download / last version links.

Actually, I scan the last tag on maint branch using git descirbe; the
ANNOUNCE posts are scanned by the RSS feed. Originally, git-scm scanned
kernel.org download directory for the latest tarball, but it seemed that
would break on something like the 1.4.4.5, so it also moved to the git
describe method:

	http://repo.or.cz/w/git-homepage.git?a=blob;f=update.sh
	http://github.com/schacon/learn-github/tree/master/script/get_version.rb

One Scott's concern that didn't occur to me was that a the time of
release, we could have broken links between the time tag is created and
tarballs are wrapped up. I *think* that in practice, this happens at the
same time, I wonder if Junio could confirm that.

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie

  Hi,

On Sat, Jul 26, 2008 at 12:07:03AM -0700, Scott Chacon wrote:

On Fri, Jul 25, 2008 at 6:53 PM, Petr Baudis [off-list ref] wrote:

quoted

 Plenty of minor fixes are available for pull at

       git://github.com/pasky/learn-github.git
       (http://github.com/pasky/learn-github/tree/master)

I've pulled in all this stuff and it should be live now.

  thanks.

quoted

 Other non-trivial nits:

 * I'm feeling a bit uneasy about listing so many projects using Git;
I haven't heard about quite a few of these and I'm not sure on what
merit should we list projects. "Prototype" or "Liftweb" and probably
even "Rubinius", is that going to ring a bell for major part of visitors
so that they say "oh, even _those_ guys are using Git"?

Based on a conversation in the other thread, I think we should have a
list that is suggested by the community and just have the 3 or 4 that
are really famous (Git, Linux, RoR...) and have the rest randomly
pulled from that list - changed every day or so.

  Maybe it is because of my general background, but I think X.org, WINE
and Fedora (probably in this order) really belong to the list as well.
If you say Prototype and MooTools are huge projects that are very
well-known in the web programmer community too, it makes sense to
include them as well; and that would be it. I might add

	<p align="right"><em>...and many more</em><p>

below the list.

  Having some of the list randomly generated is an interesting idea, but
it should be clearly visually separated from the static part, and it
would probably take a bit of work to tune this to show only interesting
projects ($size * sqrt(activity)$ or something).

quoted

 * Reusing captions from command manpages in the Documentation page
shows nicely how awful they sometimes are. :-) This is probably something
to fix upstream, though.

I saw you changed some of these, I can take another pass.  I'm not
entirely sure how useful it is to have the commands on that page, to
tell the truth.  This may go away as the documentation page evolves.

  I agree. I changed none though, I just reordered some of the commands.

quoted

 * Is "Git for the lazy" really unique in some regard to deserve to be
listed among the other resources? I think we should minimalize
redundancy at the documentation page, the amount of material is already
overwhelming and it should be obvious for the visitor which document to
choose based on his needs. I have similar doubts about the 37signals
resources.

       In other words, "let's keep the resources orthogonal!"

I agree - I would like to pull a lot of the information in those links
into one open-source book that is kept up by the community and hosted
at this page.  The documentation page will change significantly as we
try to simplify and maximize the usefulness of the page.

  But that's a long-term project, I'm talking about the usefulness of
some of the links right now.

quoted

 * There is no reference to the Wiki in the documentation, only to the
[GitDocumentation] page; I think there should be a reference to the
[GitFaq] page too - a lot of important points that are not obvious
to newcomers are covered there. I'm just not sure where exactly to put
the link.

 * I would go as far as put the link to the Wiki itself to the
navigation bar, simply since it is such a crucial resource.

Perhaps I should just do this - would that cover the previous one as well?

  It seems you did, which is great! I think there should be a direct FAQ
link as well, though.

quoted

 How does that compare with the Git user manual? Have you considered
collaborating on that one, or what are your reasons not to? Or are you
trying to do something different?

I would like to - I have personally found that invaluable in learning
Git, but I would like it to be more digestible and I would like to add
a lot of supporting media to it - screencasts and diagrams, to help
people that are more visual learners. Loading up a document where the
TOC is several pages long is intimidating and difficult to start and
stop with.

  Making it more digestible is certainly a worthy goal. :-) I think both
screencasts and diagrams could be valuable for the user manual, but
the question is how to best integrate them into the manual and if it
makes sense to do this within the Git tree, or how to cross-merge.
However, at the documentation side I focus pretty much exclusively on
improving the reference documentation, so that's not for me to discuss.

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie

El 26/7/2008, a las 7:30, Scott Chacon escribió:

However, that being said, it's going to be difficult to have Github
projects not dominate the list a bit.  The fact is that it hosts far,
far more projects than any other single hosting service.  Just in
fully public projects, the current stats (from the website pages) are
something like this:

kernel.org : 475
repo.or.cz : 1,553
gitorious   : 780
github       : 10,560

It hosts far more than that if you include private projects, too.  So,
if we want to choose totally randomly, it's going to be at least a 5:1
ratio between github projects and all other public hosting providers.

I think those numbers are pretty meaningless seeing as GitHub  
encourages people to publish "forks" of other projects. Rails, for  
example, has about 270 forks at the time of writing. If I scan the  
list of popular projects I see fork counts like 129, 105, 78 and 78  
(again). Are all the forks counted in that figure of 10,560 that you  
count? How many "real" projects are hosted there?

I'd like to see the "official" Git homepage as distanced as possible  
from GitHub. They've taken Git (free as in speech, free as in beer)  
and built a closed-source commercial product on top of it -- curiously  
for something which you can do for free yourself anyway -- and as far  
as I can tell from observing this mailing list and watching the  
commits going into git.git, haven't ever contributed _anything_ back  
to the community. At least within the niche that is the Ruby/Rails  
community, GitHub has basically done a hijack job and managed to  
become synonymous with Git, supplanting it, and it's a trend that I  
wouldn't like to see continue.

Just my personal opinion, but GitHub doesn't provoke any warm fuzzy  
feelings here. Quite the contrary. I actively dislike it.

Cheers,
Wincent

On Sat, Jul 26, 2008 at 8:48 AM, Wincent Colaiuta [off-list ref] wrote:

El 26/7/2008, a las 7:30, Scott Chacon escribió:

quoted

However, that being said, it's going to be difficult to have Github
projects not dominate the list a bit.  The fact is that it hosts far,
far more projects than any other single hosting service.  Just in
fully public projects, the current stats (from the website pages) are
something like this:

kernel.org : 475
repo.or.cz : 1,553
gitorious   : 780
github       : 10,560

It hosts far more than that if you include private projects, too.  So,
if we want to choose totally randomly, it's going to be at least a 5:1
ratio between github projects and all other public hosting providers.

I think those numbers are pretty meaningless seeing as GitHub encourages
people to publish "forks" of other projects. Rails, for example, has about
270 forks at the time of writing. If I scan the list of popular projects I
see fork counts like 129, 105, 78 and 78 (again). Are all the forks counted
in that figure of 10,560 that you count? How many "real" projects are hosted
there?

Actually, no - I was including forked projects in the repo.or.cz count
and _not_ including forks in the github count.  The actual apples to
apples count is :

Unique Projects:
  repo.or.cz: 1553
  github: 10,560

With Forks:
  repo.or.cz : 1349
  github : 16,021

Again, that is only the free, public projects - there are far more if
you include the private projects as well.  I understand that the
commercial side that is necessitated by that is uncomforting to many
people, but it is great for the adoption of Git.  Otherwise, every
company that wants to use Git professionally, including freelancers
and consultants, would have to setup, manage and maintain their own
git servers.  It should not be a precondition that in order to use Git
on a commercial project you either have to be a) a systems
administrator capable of setting up and running your own server (and
keeping it secure, etc), or b) part of an organization large enough to
have a department to take care of that for you.  Sure, you and I can
do it, and it's easy for us, but that is not true of everyone.

I'd like to see the "official" Git homepage as distanced as possible from
GitHub. They've taken Git (free as in speech, free as in beer) and built a
closed-source commercial product on top of it -- curiously for something
which you can do for free yourself anyway -- and as far as I can tell from
observing this mailing list and watching the commits going into git.git,
haven't ever contributed _anything_ back to the community. At least within
the niche that is the Ruby/Rails community, GitHub has basically done a
hijack job and managed to become synonymous with Git, supplanting it, and
it's a trend that I wouldn't like to see continue.

Again, very few of us are excellent C programmers - I'm sure you
wouldn't want any patches we have to offer there.  We have spent
considerable time and resources on things like gitcasts (which github
sponsors for me), and on libraries and tools like ticgit (which is
being included in the next Debian release) and Grit (a ruby/git
library that runs Gitorious, and probably most other web-based Git
repos), and will be contributing back improvements to ssh libraries
that allow for the sort of traffic they have to deal with.  They have
also been looking to fund further open-source git related projects (in
case any of you are interested, btw) :

http://github.com/blog/107-supercharged-ruby-git

Just my personal opinion, but GitHub doesn't provoke any warm fuzzy feelings
here. Quite the contrary. I actively dislike it.

Cheers,
Wincent

I'm sorry you don't like us, but we're really not that bad.  If you're
in the SF bay area sometime, send me a note and I'll take you out for
a beer and we can discuss what else we can do :)

Scott

Petr Baudis [off-list ref] writes:

One Scott's concern that didn't occur to me was that a the time of
release, we could have broken links between the time tag is created and
tarballs are wrapped up. I *think* that in practice, this happens at the
same time, I wonder if Junio could confirm that.

Heh, and you did not Cc: me ;-)?

There is a mirroring process involved between the public machines and the
machine I push the tag into and place the tarballs.  I do not have control
over that mirroring.  But modulo that, the tarballs and RPMs are made
public before the tag and the tips of branches are pushed into the public
repository.

The release procedure goes like this (extend this as an addendum to
Documentation/howto/maintain-git.txt if somebody feels like it):

 * On the development machine outside k.org, create the tag, and prepare
   RPM for i386;

 * scp i386 RPM to a private staging area at k.org, and push the tag to a
   private building area also at k.org;

 * run the release procedure in the private building area at k.org, which:

   - builds x86_64 RPM and deposits it to the same private staging area
     i386 RPM were scp'ed to earlier;

   - builds the source tarball and documentation tarballs;

   - puts all of the above in /pub/software/scm/git/ to be mirrored out;

   - extracts html documentation tarball in /pub/software/scm/git/docs/v*
     to be mirrored out;

         http://www.kernel.org/pub/software/scm/git/docs/, the "current"
         documentation page, has links to these "documentation for
         released versions" and they point at these docs/v* areas.

 * push the tag and branch tips out to the public repository, so that it
   will be mirrored to /pub/scm/git/git.git/ (this updates the "current"
   documentation pages as a side effect);

 * send out the release announcement message to the list.

The 1.4.4.5 backport was an oddball.  I do not think I did anything other
than simply pushing the tag out.

Wincent Colaiuta [off-list ref] writes:

I'd like to see the "official" Git homepage as distanced as possible  
from GitHub. They've taken Git (free as in speech, free as in beer)  
and built a closed-source commercial product on top of it -- curiously  
for something which you can do for free yourself anyway ...

I do not share that sentiment.  It is perfectly fine for somebody to offer
managed git repositories as a commercial _service_ to people who want to
just _use_ git.  It is what they could do themselves, but from the end
user's point of view, it's just "outsourcing" and is nothing unusual.

If GitHub folks improved the core part of the system while building their
service, we would want to get the changes back, and we will, _if_ they
distribute their software (i.e. they are not allowed to just distribute
binaries, if it links with git).

At the emotional level, if some people make the world a better place by
building new software around what I wrote, I would like to have the same
kind of access to its source as I gave them access to my sources, whether
they distribute the end product as packaged software or they offer it as a
service to be used by others without ever distributing anything.  But that
is merely my _wish_; it is different from the terms git is distributed
under.

I think you are going a bit too far to hate them for not opening up their
sources they use to implement "managed git repositories service", which is
a _user_ of the core git, but most likely is not a derivative of git
itself.  IOW, it's not your code.