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 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

--

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,
I do not like the implication that Git eats trees.
I also do not like that the link to "Documentation" looks more like a 
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
--

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 <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

--

Hi,
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
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

--

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

--

Hi,
  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
  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
  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,
  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]...
[ message continues ]

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
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
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
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
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

--

Hi,
  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
  But that's a long-term project, I'm talking about the usefulness of
  It seems you did, which is great! I think there should be a direct FAQ
  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

--

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.
--

				...
[ message continues ]

These two are directly related.  They might be friendly and well-meaning

folks, but I agree that they haven't earned our trust yet.
But I do not think it matters that much.
The thing is, git.or.cz may have been the closest thing to the "official"

homepage we have had, but that is not because Linus or I or Shawn declared

the site is official and/or that the site is trustworthy.  It was because

you put efforts preparing the contents worthy to be one-stop shop for git

related information, back when there was no such thing.  And the members

of the comminity found it a good site.  And you have the wiki there, where

there truly have been community participation to enhance the contents.
For me personally, pages outside the wiki have never felt like "the

official git homepage", not because the contents you prepared were

inadequate, but because I did not see much community participation to help

enrich it.
So I wish the new site success, but the definition of success from my

point of view is not how many random visitors it will attract, but how

well the site makes the contributors (both to git software itself, and to

the site's contents) feel welcomed.  Maybe in time it will become

successful enough by _my_ definition of success, and I may recommend

kernel.org folks to point at it from http://git.kernel.org/ (link with

text "overview") if/when that happens, and I may start mentioning them in
Let me thank you for maintaining not just git.or.cz/ but also repo.or.cz/

and the wiki.  I personally never visited the "Homepage" but the

repositories and the wiki are valuable services you gave back to the

community.
It's also somewhat interesting to observe that several people I have never

heard of in the git circle are simultaneously doing new git books,

apparently never asking for much technical advice from core git people, by

the way.

--

I agree; I think this might have been in part because the Wiki was so

easy to use and change; I did receive some patches, but not any
The question is, however,is whether to make the _current_ overview link

target simply alias at the new site _now_, though. :-) It seems to be

a waste to maintain two websites in parallel, as well as actively harmful

and confusing for people interested in Git, as I tried to explain in
Thanks, I appreciate this, though pretty much all of this sort of popped

up simply because I had root access to a bored server. ;-) Especially

wrt. the wiki, I think it's mainly Jakub Narebski who is keeping it

together content-wise and keeps bugging me if it falls apart

technically.
--

				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

--

To be honest, I have asked for a fair amount of technical advice from

many helpful people in the IRC channel over the past few years.  In my

case, one of my best friends - the guy I've been working with for the

last 4 years - is Nick Hengeveld, who has something like 50 commits in

there - why email the list when I can yell a question over the cube

wall?  I'm sure you all have more important things to do than review

my book for newbies - I asked Nick to do it.
If I could code C worth a lick, I'm sure I would have contributed more

to this list, but since I have nothing that I feel would be helpful to

you, I've passively followed the list.  I'm sorry that you do not

consider me a "git community member" just because I don't code C, and

so I can't contribute helpfully to core.
However, I have evangelized Git in person to literally thousands of

people, and tens of thousands more online.  GitHub hosts over 10,000

public git projects completely for free, and has contributed a ton

back to the community, both in code and proselytization efforts.
I hope these things can be taken as proof that we are not simply

friendly and well meaning, but that we have contributed meaningfully

to the adoption of Git and are just as committed to it's improvement

and success as nearly anyone on this list.
We want to help - help you with resources, help new people learn git

quickly and easily, and help the unconverted see the light.  We highly

respect you guys and most of the time you don't hear from us because

we don't want to bother you and take your time away from improving our

favorite tool.
Feel free to contact or email me at any time with questions, or

suggestions for improvement - schacon on IRC, schacon at gmail, or

thescottchacon on AIM.
Scott

--

I certainly agree that GitHub has done a lot for spreading Git; the

mention of code is interesting, though. There is Grist and the GitHooks;

anything else? It's a pity Grist wasn't even announced at the mailing

list. :-(
				Petr "Pasky" Baudis

--

And neither project was added to Git Wiki:

  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
It looks like GitHub-bers are a bit of splinter faction.  Thank you

Scott Chacon for trying to change this...
P.S. What about http://git-scm.org/ ?

--

Jakub Narebski

Poland

ShadeHawk on #git

--

This domain is kept by Jonas Fonseca and it seems to be used at

occassions. It traditionally pointed to git.or.cz; thus I think it would

make sense for it to keep following git.or.cz unless/until we decide to

repoint that to git-scm.com. Jonas?
				Petr "Pasky" Baudis

--

I claimed git-scm.org after the last survey since a few people

mentioned that they found the git.or.cz domain name a bit obscure. I

am aware that the my current lack of involvement in git development

(which is mostly limited to documentation improvements) and the

resulting possible lack of trust from the community has limited its

use. However, I hope that it can serve some purpose in the future

whether it will be as an alias or not. I have am open for suggestions,

but for now I trust you and will follow your advice in this matter.
--

Jonas Fonseca

--

Huh?  Lack of trust?   Don't be ridiculous to forget "tig".
--

Ah, Nick.  We haven't heard from him for quite some time.  I've actually

been missed him from time to time whenever http related issues came up.
I realize I may have sounded somewhat harsh, but that was not my

intention.  And I do not think what you said is fair, either.
We have had quite a few end user questions on this list, but I do not seem

to recall any of the names of the book writers, whose books are presumably

aimed at these people, answering them.  Granted, core coders may be busy

bunch of people, and the questions and comments from new people sometimes

tend to be lost in flurry of patch floods.  I and other core coders would

have greatly appreciated if non-coder experts like yourself helped these

threads that have never panned out.
I am not complaining.  This cuts both ways.  The patch floods do tend to

discourage new people from asking basic questions, and lack of answers

even more so.  But it is not healthy for people who design and code not to

hear end user feedback.  I personally would want to see the list traffic

to be inclusive.
The people who design the new features and write code should have easy

access to the issues the users of all levels have with the software and

the documentation (and what they find useful as well).  What I am most

afraid of is that both "We do not bother the coders" and "We are too busy

to answer every newbie question" mentalities would lead to a fractured

community.

--

The community is already fractured! I think we actually have very tiny

fraction of the user base on the mailing list - the traffic is simply

too massive. After all we chose _our_ convenience over _users'_

convenience in making this tradeoff. Also, as I mentioned in the other

mail, it's not obvious to me whether major part of our community would

be willing to participate in any mailing list at all.
(Note that I don't want to imply that this would be inherently a Bad

Thing. Some feedback still bubbles through and we have ways like Jakub's

Git User Survey as well. Maybe the user community is by now simply too

big to make the direct cross-pollination with developers feasible.)
There was a proposal some time ago for making a web forum for Git; maybe

we were too dismissive to the suggestion. I wonder where *do* these 100k

of registered GitHubbers get their Git support now? :-)
--

				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

--

Perhaps it would be useful to split the mailing list into core/contrib

and support lists?  I would be happy to help out answering questions -

a lot of them come directly to me anyhow because of the gitcasts site

and such.
Scott
--

A git-user list would be welcomed at least by me. It remains to be seen

how useful it would be (and stay) as often the user lists for a project

dwinddle a bit but I've subcribed and unsubscribed to this list a number

of times now since unless I've a specific question to ask, the list is

too busy too just sit around on; I end up deleting all list mail unread

every night anyway, so I just unsubcribe again.
Maybe a less busy and less implementation focussed list could help "me

and mine" gradually pick up new tips and tricks. Depends ofcourse on

willingness of some of the more proficient to be involved in that list

as well...
Rene.

--

Well, there _is_ separate Git Users Group at Google Groups

  http://groups.google.com/group/git-users

  nntp://news.gmane.org/gmane.comp.version-control.git.user
--

Jakub Narebski

Poland

ShadeHawk on #git

--

Perhaps I should link to that on git-scm as well / instead?
Scott

--

It is mentioned at http://git.or.cz/gitwiki/GitCommunity at the end
"As well" I can agree with.  "Instead" I'm against that.
Git mailing list doesn't require subscription, and allow sending

emails using Usenet/news reader from GMane NNTP interface/gateway.

Not so with Google Group.
--

Jakub Narebski

Poland

--

There, fixed that for you.
--

Cheers,
Sverre Rabbelier

--

Hi,
FWIW my criticism in the same direction was met with ridicule, which does

not let me expect much of them.
Ciao,

Dscho
--

Oh, mine was not a criticism but was just an observation.
Maybe the folks we consider as "git community members" are either too

narrow, or too detached from the "real user community", and it could be

that git books are better written without us.
I am not being sarcastic nor sardonic; we may simply be too close to git,

we may have been breathing git for too long, and what feels the most

natural thing to be taught first for us may not be the best first thing to

be taught to the new people (even though they may eventually grow to think

like we do when they become proficient enough).

--

I would say we actually worked hard to make itpossible to understand

Git without being a Git contributor and knowing the code inside-out,

didn't we? So in a sense, having books about Git written by people

outside of the developer community could be considered a certain

milestone for Git usability. At least provided the books are good, and

reading the excerpts from
	http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git
has been a little disturbing experience at times. Then again, it is an

early alpha probably far before technical editing, so it is too early

to draw conclusions. (And after doing technical editing for a very thick

Czech book on low-level Linux programming, my standards for this phase
  The numbers in another part of the thread show something important -

GitHub is more than SIX TIMES BIGGER than repo.or.cz! How many of you
	http://github.com/blog/99-popular-languages
Overally, it seems that Git is getting huge traction in the web

developers community while this is something I would presume the core

Git community of kernel hackers and such is mostly unaware of (and it is

somewhat amusing contrast). Now, these are people who we will probably

never see on the mailing list, not just because they frequently don't

even know C, and don't care to, but they might have actually never used

a mailing list before! These are the people who frequently could not

care about their VCS' internals less and finding out that Git works well

enough for them is something rather satisfying for me personally.
  I don't know if this should have any immediate effect on how we

develop Git etc., but I think it is good to be aware of the fact that

silently, huge amount of "dark mass" Git projects is accumulating and

that Git is making headways in areas many of us were little aware of.
--

				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

--

The developer community and "dark matter" community are totally separate

entities that do not interact with each other very much, and they will go

their separate ways?  I think it is inevitable for any project once it

becomes popular enough.
Where does this observation lead us in this "Official" git homepage

discussion?  Perhaps the conclusion would be that there does not have to

be any _single_ official home?  I dunno.
--

I don't think this is inevitable. I think we are getting into this

position two few simple reasons:
  (i) The traffic on the main list is simply too high for regular users

to keep up with. If we care to get more in touch with our users,

the solution might be to spread the word about the Git Users Google

Group more, and monitor it more actively.
  (ii) The tone on the mailing list seems frequently unnecessarily

harsh. This was mentioned by some of the "dark matter" people (not Scott

himself) as the reason why didn't they announce their work on the

mailing list; fear of being flamed. Especially at the beginning of

summer when I "returned" after quite a while of inactivity, I perceived

this rather unfriendly tone rather strongly as well (not at me

personally, but reading replies to other people's contributions), though

I got kind of used to it quickly again. If we care to encourage postings

by "external" developers to the mailing list, we should keep the usual
  That is not good idea; this would only split the community further,

*and* create confusion as some people would be directed to homepage A,

others to homepage B, each would have its resources kept up-to-date

in different manner, ...
  Also, we need someplace to link at from git itself:
	README:Many Git online resources are accessible from http://git.or.cz/

	gitweb/gitweb.perl:our $logo_url = "http://git.or.cz/";
In case of README, we could add another link easily, in case of gitweb,

much less so.
  This ultimately comes down to what address would *you* write on

a piece of paper if someone walked to you on say, some conference

and asked you "I like Git, where can I learn more?" Or you could start

explaining how Git does not have a single homepage and start writing

multiple URLs noting the differences. Would that make good impression?
--

				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,
I heard this a lot of times now.  I think it is not "harsh", but "direct".

There is nobody saying "you are a bloody fool".  At least not in the first

response, and certainly not without explaining why.
Sure, I, for one, am not overly polite.  I do not start my mail with "It

is such a nice thing that you decided to provide a patch.  I am certain

that you know C pretty well, but there _might_ be a few _tiny_

improvements, would you indulge with me to let them lay out in front of

you?"
I do not do that because it goes without saying in Open Source that I

would not _bother_ to reply if I was not interested.  And it Just Wastes

My Time.
Maybe I should start my mails with "Disclaimer: I only reply to you

because I am interested in your patch."
Ciao,

Dscho
--

On Sun, Jul 27, 2008 at 17:53, Johannes Schindelin
That might actually be a good idea, maybe add it as your signature ;). *ducks*
--

Cheers,
Sverre Rabbelier

--

I would disagree.  If there is already a sporadic mess of GIT-related

information, not having somewhere "official" to collate and track

development changes in documentation, etc., could be very confusing

indeed.  There is no guarantee these so-called "dark-matter" people

would ever get around to updating anything they're currently writing

which would be disasterous.
-- Thomas Adam

--

Hi,
Yet, when I see obvious errors, I have an urge to correct them.  I know,

it is wrong, it is not my itch, and I know I will get crap for it.  But I

just cannot help myself...
Ciao,

Dscho
--

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.

--

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
--

Hi,
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
--

Hi,
  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

--

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
--

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
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) :
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

--

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 
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

--

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

--

You have to work harder to do the real research to find such key

historical documents than just linking to the toplevel of the current

repository, but I think this is an excellent idea.  And most likely many

projects that have migrated from elsewhere (not the ones from scratch that

did not migrate from any existing codebase) could volunteer relevant links

if asked politely enough ;-)
--

I think counting merges in "The Authors of Git" statistics give quite

skewed numbers.  If you are generating it with "shortlog", you probably

would want to give --no-merges to the command line as well.  Also it

appears that you are not using .mailmap to avoid counting the same person

as different people.
I find a tabular list like this list easier to read if it were sorted like

this:
	A	D	G

        B	E	H

        C	F
i.e. not like this:
	A	B	C

        D	E	F

        G	H
--

Thanks Junio,
I fixed the things you mentioned here, except for the list ordering,

only because I kinda think you big contributors should be at the top

there, and also because it's slightly more difficult to populate an

html table that way :)  If everyone feels strongly about that, though,

I will change it.
Scott
--

If you are going to list 30 or so top contributors in 8 rows times 4

columns, because visually the columns are much more distinct than the

rows, it makes the result look more sorted.  This is the same reasoning

hwo "git help --all" was fixed with 112d0ba (Make "git help" sort git

commands in columns, 2005-12-18).
By the way, I think this shows another issue with the "rest of us" list in

the lower half.
I have a mild suspicion that sorting that list in alphabetical order may

actually make it much better.  It all depends on the purpose of that list,

though.
The purpose of the list would most likely not to find somebody with high

activity to contact for help (you would use the top list that is sorted by

the commit count for that kind of thing).  It would primarily be to give

credit to everybody, and perhaps so that people on the contributor list

can point at their own name and say "I helped them", or find somebody else

they happen to know in the list.
When a contributor used to have 8 commits and then adds 2 commits, that

would move the name in the list by a dozen places or so with the current

set of contributors.  It would be much easier to locate one's own name

among a huge list if the names are alphabetically sorted, not by commit

count.  When more people start to contribute, your name does not move so

drastically.  If you are Adam, you are likely to find yourself near the

beginning of the list, if you are Scott, you are likely to find yourself

near one fourth from the end of the list.
And for the "giving credit" purpose, I do not think truncating the list at

5 commits or less threshold, as suggested earlier and already done, makes

much sense, either.

--

Actually, this is strange for me: I would never think about reading git

help --all by rows, and I would never think about reading the authors

list by columns! It's difficult for me to point out why, possibly

because the authors list has less items per row and the items are longer

(and multi-word), but that's just a speculation. Maybe cultural

background (Japanese books are written in columns, right?) plays some
I don't think locating is any issue; the find function of browser is

very easy to use nowadays. I guess the purpose of the list would be

to show "I helped them this much" (i.e. "I'm high on the list"). I think

this would actually motivate contributors to move up in the ladder -

people are competitive; you might get wary about this kind of

motivation, but I believe that it is no bad thing, inherently. Heck, I

admit it does motivate even me a little, safely in the "Primary Authors"

section. :-) (These guys with their tools merged into git have unfair

advantage! You should add up also, uh, git-homepage, cogito and, um...
The point here is that the list is awfully long and also can contain

a lot of duplicates or people with broken unicode, etc. - it gets hard

to maintain, and it makes the about page too long. I would be of course

fine with a tiny link at the bottom "(show all contributors)".
--

				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

--

I do not think the default mode of "ls" output to tty (aka "ls -C") was
Your "incentive to move up" argument suggests otherwise.  Even if it takes

efforts to maintain on somebody's part, it is worth to be inclusive, *IF*

the purpose of that bottom list is to give credits to people.
The list on the site originally was not utilizing .mailmap and I asked

Scott to use it to merge duplicate entries, which he did.  People whose

names are misspelled and/or split will now have incentive to tell Scott

about the problem so that they can clean up *their* own names, and Scott

can help maintaining .mailmap and feed the changes to me.
This is my ulterior motive behind this suggestion; I can outsource the

maintenance of .mailmap to people who care about it more than myself.
--

By the way, earlier Scott gave as explanation why he and others around

GitHub, people who are not very visible on this list, are not interacting

with us very much --- because they are not "C coders".
But maintenance of .mailmap (and Documentation/ area, too, of course) is a

good example of how involvement from non "C coders" would be a helpful and

healthy thing to have in the development process, and why we do not want

to fracture the user community in two.

--

Well, I'm not a C coder either ;-) -- plenty of the large contributors

do their work in Perl Python and shell. Granted, I am not very active

lately, but that's because I'm busy on non-git-related (but

git-using!) projects.
And the choice of language has nothing to do with helping people

around. If they care about getting recommendations from list regulars,

anyway. Maintaining a great user-facing website might be their way of

engaging and interacting with us.
cheers,
martin

--

 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

--

On Sun, Jul 27, 2008 at 4:19 PM, Martin Langhoff
As cofounder of GitHub I'd like to jump in and say a few words. I'm a

huge fan of git. HUGE. But that should already be obvious. We started

GitHub because we saw that git was a tremendously useful tool but was

missing a way to easily and flexibly share your public and private

code with other developers. That simple idea grew into what we now

like to call "Social Code Hosting."
I find it a bit confusing that some here seem to have a strong dislike

for GitHub. It's true that we haven't been active on the developer

list or in the #git channel on freenode, but we are constantly in

#github and have answered a *great* many questions from developers

that are new to git. At the same time, like Martin finally guesses, we

believe that our contribution to the git community is GitHub itself.

We provide free git hosting for over 16,000 open source repositories!

As mentioned earlier in the thread, the Ruby-Git binding that Scott

and I wrote has been open source from the beginning. While we did not

announce it here, we have publicized it in the Ruby circle (where,

presumably, people would most likely find it useful) and in fact there

are currently 28 forks and 138 watchers of the project. We've also

released albino, facebox, and github-services via GitHub. You can see

all the open source stuff we use at GitHub here:

http://github.com/github.
Perhaps it is the commercial aspect of GitHub that offends. The only

reason that GitHub is as featured and polished as it is, is because we

can make money from it. We hope to soon be working on GitHub full

time. There is no way this could have been possible if we did not

offer paid private repositories. A part of being a commercial

operation is making the main product closed source. One might argue

that we could still have GitHub as a service while making the code

open source, but the truth of the matter is that this is not in the

best interest of our future plans for the company.
I don't like the thou...
[ message continues ]

Hi,
Speaking for myself, I will probably direct some users from #git to

#github, then.
The deeper reasoning: if you really do help by that channel, by all means 
I find that limiting to the Ruby circle particularly unconvincing.  Sure,

they might care much more than me.  Much more, to be sure.
But when _I_ -- being around the Git list for a long time -- do not _know_

about something like a pretty well-working Ruby-Git binding, instead only

knowing a pretty stale effort on repo.or.cz by "corecode", then I think

communication channels are suboptimal.  Way supoptimal.
Because at times _I_ am asked if there is some Git interface for Ruby, and

it feels awkward that I am pretty familiar with Git's internals and

community, yet I do not know about such an _important_ piece of software 
In my opinion you can be as commercial as you want.  Nevertheless, I would

like to see some direct benefit for me, too, for obvious reasons.  That

does not need to be money; like Junio said, watching out for user

questions on the Git list would already be very useful, in two respects:
- the core developers have more time for hacking on Git itself (which

  would be good both for the developers as well as for you),
- if your advices can be enhanced (such as my gripe that "git show" is not

  even so much as mentioned, in spite of being _the_ porcelain to inspect

  objects in Git's object database, not cat-file, whose only role in

  tutorials can be to shoo new users away) it will be early, which again

  is a win-win situation for both core developers as well as for you, and
- just as in the past, I fully expect the main thrust of the major changes

  in Git to be driven by user experience (just think of Git 1.5.0), and by

  driving users away (and indeed, by driving yourself away, a bunch of

  power-users), you would make that much more unlikely to happen in the

  future.  So, having you closer to the Git mailing list and #git would
I might mention here that I think you are ...
[ message continues ]

On Mon, Jul 28, 2008 at 3:50 AM, Johannes Schindelin
By all means! The users might be a bit confused about why you're

sending them to #github, but we're happy to help them out if you don't

care to. We actually employ a support person to man the channel and
Using this same logic, it follows that we GitHub developers would be

better suited to hacking on GitHub (which would be good for the git

community). There are only so many hours in the day. I've had many a

GitHub user tell me that the GitHub interface and functionality helped

them finally understand git and feel comfortable switching to it from

SVN or CVS. It seems we can help bigger populations of git users by

making the site as clear and easy to use as possible, so that is what
I totally agree with the direction that 1.5 has taken git. You guys

are doing an awesome job with user experience. As I come across
The problem is that I'm only a casual C coder. It takes me a while to

figure out what's going on in the git source. We needed a way to serve

public git repositories from a hashed directory structure (e.g.

/a/b/c/user/repo.git) and we needed it fast. In a few days worth of

coding Erlang, I was able to meet that need (and also add logging and

better error messages returned to the client). If I had, as you

suggest, created a badly written patch and asked for help on the list,

I'd probably still be trying to solve the problem. It's dubious that

anyone other than us currently needs to satisfy the hashed directory

requirement, and as such I would not assume or expect that anyone

would be motivated to spend a bunch of time helping a C amateur

satisfy that need. In the end I was responsible for making it work,

and I did that the best and most efficient way I knew how.
Like I said before, I'm happy to share my suggestions for better error

messages and logging behavior, but I'm probably not going to be much
This is clearly false and does not do Junio or Shawn justice. It's not

hard to imagine that these two (or any of the o...
[ message continues ]

I'm not exactly sure what you mean by "hashed directory structure",

but I suspect that your goal is some form of virtualized hosting

that allows for directory names to be dynamically constructed with

a component that appears to be the user name.
Wouldn't the --interpolated-path ability of git-daemon either

directly or with minor modifications directly support that?
jdl
--

Tom, correct me if I'm wrong, but my understanding of this is that,

with GFS, they were running into the problem of too many dirents in

one directory, thus causing lots of stability problems (GFS has a far

lower limit than other filesystems in this regard). So the GitHub guys

had to switch to a directory sharding structure (similar to how the

git objects db uses the first 2 characters of the hash as the dir

name) to split this up and keep the numbers manageable. However, they

still had to support the old git://github.com/user/project.git paths.
-Kevin Ballard
--

Kevin Ballard

http://kevin.sb.org

kevin@sb.org

http://www.tildesoft.com
--

As a contributer with a single commit I was happy to see myself appear

shortly on the list (yeah!). Ok, so I realize it is vanity and a little

silly... :-)
To me it makes sense to sort the entire list according to commits. Its

still easy to find anybody with search, and I find it appropriate that I

be towards the end. The commit sorting encourages me to move up the 
And why truncate the list? I'd personally like to be back on the list

(vanity! - but true), bandwidth is relatively cheap, and there is

nothing below the list. I also think it makes the community look healty

and encourages contribution to see how many others contribute.
Peter

--

Peter Valdemar Mørch

http://www.morch.com

--

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 <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

--

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

fixed shortly.
Scott
--

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, <johan@herland.net>

www.herland.net

--

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
--

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

--

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
--