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 <schacon@gmail.com> wrote:

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

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 <alturin@gmail.com> wrote:

On Friday 25 July 2008, Scott Chacon wrote:

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

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

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 <s-beyer@gmx.net> wrote:

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

On Fri, Jul 25, 2008 at 4:47 PM, Junio C Hamano <gitster@pobox.com> wrote:

"Scott Chacon" <schacon@gmail.com> writes:

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.

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

Junio C Hamano gitster-at-pobox.com |Lists| wrote:

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 list! :-D

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

On Sat, Jul 26, 2008 at 10:10:32AM -0700, Junio C Hamano wrote:

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 role too, I don't know.

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... repo.git! *baby cry*</vanity>)

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 Baudis <pasky@suse.cz> writes:

I do not think the default mode of "ls" output to tty (aka "ls -C") was invented by/for Japanese people.

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.

Junio C Hamano <gitster@pobox.com> writes:

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.

On Mon, Jul 28, 2008 at 10:01 AM, Junio C Hamano <gitster@pobox.com> wrote:

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

On Sun, Jul 27, 2008 at 4:19 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:

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 thought of being at odds with the git developer community at all, and let me be the first to apologize if we've offended anyone. It certainly is not our intention. Our goal with GitHub is to help make git even better by offering a service that helps people streamline their git workflows and discover projects that may interest them. We're trying to give back to the community how we know best: by offering kickass git hosting and associated collaboration tools.

Having had to implement a git-daemon replacement that fit our needs, I have some ideas on how to improve git-daemon and fetch-pack with regards to error messages and logging. I'll be sure to bring those up on this list. One thing you should probably understand about us is that we're all about getting things done. Which is one reason we weren't bothering everyone in here when we started GitHub. We like to design from first principles, see how good we can do, and then get feedback from the users. If you're a GitHub user (or have a reason why you are *not* a GitHub user), we'd love to hear your feedback on ways we can improve!

Tom Preston-Werner github.com/mojombo

Hi,

On Sun, 27 Jul 2008, Tom Werner wrote:

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 want to provide you with the opportunity to do so.

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 being available!

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
  again be a win-win situation.

I might mention here that I think you are committing one of the biggest sins in Open Source: you do not reap the full power of the community.

I am sure, if you would have mentioned your needs first, possibly followed by an early version of a patch, git-daemon would already be enhanced to your liking, and these enhancements would be available to everyone (including me, for example). But maybe that being available to everyone is not in the best interest of a commercial outfit?

Maybe this is so contrary to Open Source that many are uncomfortable with it.

Also note that one of the major gripe with you making money off of Git could be the following: we have over 500 contributors, and most of them -- first and foremost of all, the two major contributors, Junio and Shawn -- cannot make money from Git. Envy is wrong, but it is real.

Do not get me wrong, I do not want to defend that behavior, but I think it is a reality that you will have to cope with.

Ciao, Dscho

On Mon, Jul 28, 2008 at 3:50 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

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 help out where he can.

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 we choose to do.

Can you clarify what you are referring to here? I'm not sure I understand.

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 usability problems I'll be sure to bring them up here in the future.

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 help with providing patches.

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 other contributors) could make money doing training for git at companies that have adopted it, or as consultants to firms that use git in novel ways, or as authors of git books. Scott Chacon gets paid right now to work on tools that use git as an underlying file system. In fact, by helping bring corporate interest to git, GitHub is paving the way for more and more people to make money from git if they so choose. I wouldn't be surprised if, down the road, Junio could be paid to hack on git full time via corporate sponsorship. The continuing advancement of git is of interest to a great many people. Some of which would gladly pay for it.

Tom Preston-Werner github.com/mojombo

Tom Werner wrote:

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

On Jul 31, 2008, at 11:39 AM, Jon Loeliger wrote:

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I saw more than several times that people asked github specific questions on #git; when they were lucky, there was somebody who knew github and they got necessary help. Otherwise the answer was "eh, sorry, that's a closed service and we cannot help diagnosing the problem you are having". It would have been the right way to help them to refer to the #github support channel.

If a company can fund somebody to help new users with git problems on #git while helping people with github problems on #github, that would be a good gesture towards the git community, I'd suppose.

I do not talk for Shawn, but I think that comment misses the mark by a large margin, at least for me.

I haven't been in this for money. The original motivation of my involvement was to help sending Linus back to the kernel as quickly as possible, but now I primarily do this for fun. Doing it for money would risk removing the fun factor.

What I personally lack right now is time and mental bandwidth.

Active contributers of all kinds, ranging from "C coders", "scripters", to "Documentation people" and "dropped patch naggers", have been helping me quite a lot. Corporate sponsors that can pay back in money but not in patches may be able to find other ways to help us, but I do not offhand know what's the most effective way for them to do so if they wanted to.

On Tue, Jul 29, 2008 at 9:42 AM, Junio C Hamano <gitster@pobox.com> wrote:

FWIW - not much probably - anything that pushes towards "gui-completeness" is a good step.

We have fantastic gui tools that complement the awesome cli UI, and we have some complete-ish GUIs, but the git-cheetah and Eclipse tracks are lacking. Work on those is needed - whether money can help I do not know. However, not many people work on polishing smooth UIs for love and fun.

cheers,

martin

On 28 jul 2008, at 23:42, Junio C Hamano wrote:

For what it's worth, I regularly redirect people from #git to #github, so at least they aren't always left in the dark ;)

- Pieter

Junio C Hamano <gitster@pobox.com> wrote:

I'm glad you guys think so highly of my contributions, but I am
only a small cog in the big machine known as "git".  I just happen
to like very-fine grained commits for any changes, which skews my
commit count upwards a bit.  There are _many_ contributors in that
"Primary Authors" list on git-scm.com who deserve attention too.  :)
 

Well, here you could have spoken for me I think. I do git because I find it fun, rewarding, and challenging. Though these days it has been a little bit more work and a little bit less fun-challenge as I am plowing through code for egit, but its a labor of love.

My contributions to Git are also about giving back, in return for the benefit I have gained over the years from using Linux, and the thousands of other open source packages that make it all work. I'm not big on kernel hacking (though I did try it for about 6 months) so this is one way I can put a few pennys back in the open source take-a-penny/leave-a-penny penny jar.

More recently I may be in a position where my new employer might be able to make some contribution to the community through part of my time. I shall see if it winds up detracting from the fun aspect of it for me. Personally I tend to get so focused on something that I have a very hard time moving away from it, and just want to focus on that one thing and do it well. Doing it at day-job may make that easier, and reduce stress on me, in turn making it more fun.

I don't know how much kernel.org needs support, but we rely heavily on kernel.org for our main distribution site of git. Its a drop in the bucket compared to the Linux kernel activity itself, but I imagine that the right sort of Linux-friendly (and Git-friendly) corporate sponsor could really help kernel.org out. Of course only so much help is really useful, and I have no idea what kernel.org's financial (and staff time) situtation is like, so I'll shut up now.

Pasky's repo.or.cz is another huge area that the community relies upon. Fortunately Pasky has been able to offer its services freely, but in the future it may reach a point where corporate support for adminstration assitance, duct-tape development, bandwidth or hardware, may be extremely beneficial.

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

On Fri, Jul 25, 2008 at 6:38 PM, Patrick Aljord <patcito@gmail.com> wrote:

  Hi,

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

  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

On Sat, 26 Jul 2008, Petr Baudis wrote:

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

On Fri, Jul 25, 2008 at 7:47 PM,  <david@lang.hm> wrote:

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

"Patrick Aljord" <patcito@gmail.com> writes:

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

On Fri, 25 Jul 2008, Scott Chacon wrote:

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

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

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

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 <win@wincent.com> wrote:

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.

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

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

Wincent Colaiuta <win@wincent.com> writes:

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.

Hi,

On Fri, 25 Jul 2008, Scott Chacon wrote:

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,

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

  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.

  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?

  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 Baudis <pasky@suse.cz> writes:

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 the "Note". We'll see.

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.

Hi,

On Fri, 25 Jul 2008, Junio C Hamano wrote:

FWIW my criticism in the same direction was met with ridicule, which does not let me expect much of them.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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

Hi,

On Fri, 25 Jul 2008, Junio C Hamano wrote:

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

On Fri, Jul 25, 2008 at 09:49:42PM -0700, Junio C Hamano wrote:

  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 of book development had to be... somewhat lowered. ;-)

  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
have GitHub accounts, and how many of you are actively using repo.or.cz?
:-) And GitHub is not "just" Ruby on Rails *at all*:

	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 Baudis <pasky@suse.cz> writes:

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.

2008/7/26 Junio C Hamano <gitster@pobox.com>:

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

On Sat, Jul 26, 2008 at 09:37:01AM -0700, Junio C Hamano wrote:

  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
strength of our criticism, but try to make the tone more encouraging.

  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?

Hi,

On Sun, 27 Jul 2008, Petr Baudis wrote:

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 <Johannes.Schindelin@gmx.de> wrote:

That might actually be a good idea, maybe add it as your signature ;). *ducks*

On Fri, Jul 25, 2008 at 9:09 PM, Junio C Hamano <gitster@pobox.com> wrote:

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

"Scott Chacon" <schacon@gmail.com> writes:

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. Please say hello to him for me ;-).

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.

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

On Sat, Jul 26, 2008 at 12:11 AM, Junio C Hamano <gitster@pobox.com> wrote:

On Sat, Jul 26, 2008 at 09:27, Scott Chacon <schacon@gmail.com> wrote:

There, fixed that for you.

On 26-07-08 09:27, Scott Chacon wrote:

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.

Rene Herman <rene.herman@keyaccess.nl> writes:

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

On Sat, Jul 26, 2008 at 8:21 AM, Jakub Narebski <jnareb@gmail.com> wrote:

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

Scott

On Sat, 26 July 2008, Scott Chacon wrote:

It is mentioned at http://git.or.cz/gitwiki/GitCommunity at the end of the wiki page.

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

On Sat, Jul 26, 2008 at 12:11:01AM -0700, Junio C Hamano wrote:

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

On Fri, Jul 25, 2008 at 11:43:55PM -0700, Scott Chacon wrote:

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

Petr Baudis <pasky@suse.cz> writes:

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

On Sat, Jul 26, 2008 at 01:24:05PM -0700, Jakub Narebski wrote:

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

On Sat, Jul 26, 2008 at 10:32 PM, Petr Baudis <pasky@suse.cz> wrote:

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" <jonas.fonseca@gmail.com> writes:

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

On Fri, Jul 25, 2008 at 09:09:43PM -0700, Junio C Hamano wrote:

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

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 my other mail. That's why this subthread was born.

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.

On Fri, Jul 25, 2008 at 6:53 PM, Petr Baudis <pasky@suse.cz> wrote:

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

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.

Done and pushed.

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

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

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.

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,

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

  thanks.

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

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

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

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

  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.

Hi,

On Fri, 25 Jul 2008, Scott Chacon wrote:

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.

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

  Hi,

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

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

  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.

Johannes Schindelin wrote:

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

Hi,

On Sat, 26 Jul 2008, Stephan Beyer wrote:

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 <Johannes.Schindelin@gmx.de> 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. 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 Sat, Jul 26, 2008 at 4:55 PM, Scott Chacon <schacon@gmail.com> wrote:

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

"Scott Chacon" <schacon@gmail.com> writes:

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.

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

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 Baudis <pasky@suse.cz> writes:

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.

On Sat, Jul 26, 2008 at 12:11 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

That is open to anyone that has contributed a patch to git - I at least owe you a beer. Let me know when you're around.

Scott

Hi,

On Sat, 26 Jul 2008, Scott Chacon wrote:

Welcome the masses:

$ git shortlog -s | wc -l 504

As I said, around 24th of October this year.

Ciao, Dscho

On Sat, Jul 26, 2008 at 12:20 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Heh. That would be a hell of a night... Nick Hengeveld said he's up for it too, anytime.

btw, doener pointed out that I had the repo.or.cz numbers backward earlier - it should be 1500ish with forks, 1300ish without.

Scott