login
Search
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 --
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 --
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 --
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 --
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. --
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 --
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 ...
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 ...
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 ...
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 --
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, I actually think that this is *one* reference to GitHub that is perfectly and 100% okay; if it is sponsoring the hosting, it deserves the logo, and it is fairly non-intrusive. I _am_ watching out warily for excessive GitHub references within the rest of the site - if only because I have kind of personal interest in a competitor of GitHub and thus don't want GitHub to get unwarranted free advertising. :-) Petr "Pasky" Baudis --
since this is a Ruby on Rails site, could the 'five links' that have been bothering people be randomly selected? if every time you go to the site you get a different list of projects it show how broadly git is used. it's not as 'in your face' as managing to select five that cause people to say "wow, they're using this", but different people will react to different sites. if this table gets populated by GitHub, kernel.org, and a couple other sources it should be vendor independant enough (and we need a table like this anyway for the 'list of projects that use git', so it serves two purposes) David Lang --
I would really like to have the big ones there all the time ('Linux',
'Ruby on Rails', 'WINE', 'X.org', etc) Prototype and MooTools are
pretty big in the web dev world, which a lot of people are starting to
come from - at least Prototype should be there all the time. For the
rest, if we want to pool a bunch of other projects from different
places, that would be cool, but they should be active - I don't want
people clicking on something above the fold and getting a dead
project. If someone wants to help me vet a list, I'd be happy to do
that.
However, that being said, it's going to be difficult to have Github
projects not dominate the list a bit. The fact is that it hosts far,
far more projects than any other single hosting service. Just in
fully public projects, the current stats (from the website pages) are
something like this:
kernel.org : 475
repo.or.cz : 1,553
gitorious : 780
github : 10,560
It hosts far more than that if you include private projects, too. So,
if we want to choose totally randomly, it's going to be at least a 5:1
ratio between github projects and all other public hosting providers.
If anything, statistically, the current list is conservative in it's
links to github projects. For me to avoid using them is artificially
punishing them for having paid plans, which is silly.
Scott
--
How about linking to the project web page or the official blog where the move was announced when available? I think that's how it's done on the mercurial page. And it explains people why the switch was done rather then linking to a source repository they might not care about and the link to the project page might give a hint about the importance of the given project for those that might not know it (such as prototype, mootools or liftweb). example: http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git --
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 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 --
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 --
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, 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 ...
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. -- ...
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. --
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). --
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 --
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 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 --
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 --
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 --
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. --
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 --
There, fixed that for you. -- Cheers, Sverre Rabbelier --
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 --
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 --
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". --
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 --
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, 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 --
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 --
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 --
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 --
