git-scm.com

git-scm.com

[Scott Chacon]

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

Re: git-scm.com

[Sverre Rabbelier]

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

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

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

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

-- 
Cheers,

Sverre Rabbelier

Re: git-scm.com

[Scott Chacon]

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 Fri, Jul 25, 2008 at 19:35, Scott Chacon <schacon@gmail.com> wrote:
>> A followup on the post I did a few days ago about Git documentation.
>> I forked Petr's git.or.cz site and put up a version that I think is a
>> bit more accessible and newbie-friendly at git-scm.com.  I had meant
>> to discuss this with Petr before posting it to you all, but I
>> published a blog post that got a bit more attention than I expected,
>> and I didn't want you all to think I didn't care about your opinion,
>> as some have already accused me of.
>
> I had a looksie at the site and I think the documentation section [0]
> could use some TLC. It might be because it's getting late, but there's
> not really any 'eye catchers', no "CLICK ME!" link for someone
> browsing around looking for Documentation. In order to find what you
> want you have to read -a lot- of the page, which I think is a sign
> that the page would do well with some TLC ;).
> Now I'll admit that the git.or.cz version [1] is a lot worse, but with
> this being an attempt to make it a lot more newbie friendly...
>
> [0] http://git-scm.com/documentation
> [1] http://git.or.cz/gitwiki/GitDocumentation
>
> PS: I think you forgot the </shameless plug> when you did put up your
> own e-book in the books section but did not put "Git Magic" there ;).
>
> --
> Cheers,
>
> Sverre Rabbelier
>

Re: git-scm.com

[Johan Herland]

On Friday 25 July 2008, Scott Chacon wrote:
> Hey all,
>
> A followup on the post I did a few days ago about Git documentation.
> I forked Petr's git.or.cz site and put up a version that I think is a
> bit more accessible and newbie-friendly at git-scm.com.  I had meant
> to discuss this with Petr before posting it to you all, but I
> published a blog post that got a bit more attention than I expected,
> and I didn't want you all to think I didn't care about your opinion,
> as some have already accused me of.
>
> Anyhow, I'm discussing with Petr about where we want to go from here -
> what changes he'd like to make, etc, but I obviously value your
> opinion as well, so please let me know what you think.  The content
> has barely changed, it's really just a usability overhaul.  I want to
> make sure that whatever someone is looking for (especially someone
> new), they can find in a few clicks and a few seconds.

Thanks for the update. Looks good.

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


Have fun!

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: git-scm.com

[Scott Chacon]

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:
> On Friday 25 July 2008, Scott Chacon wrote:
>> Hey all,
>
> Thanks for the update. Looks good.
>
> Minor niggle: On the download page, in the Binaries table, Cygwin is listed
> before msysGit. I'm under the impression that msysGit is what we really
> want to be pushing on Windows (it's faster, smaller, and less strange to
> Windows-people (i.e. less Unix-y)), so you might want to switch the order
> around.
>
>
> Have fun!
>
> ...Johan
>
> --
> Johan Herland, <johan@herland.net>
> www.herland.net
>

Re: git-scm.com

[Stephan Beyer]

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

Re: git-scm.com

[Scott Chacon]

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

Re: git-scm.com

[Junio C Hamano]

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

Re: git-scm.com

[Scott Chacon]

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

Re: git-scm.com

[Junio C Hamano]

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

> On Fri, Jul 25, 2008 at 4:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> 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 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,...

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.

Re: git-scm.com

["Peter Valdemar Mørch (Lists)"]

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

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

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

Re: git-scm.com

[Petr Baudis]

On Sat, Jul 26, 2008 at 10:10:32AM -0700, Junio C Hamano wrote:
> "Scott Chacon" <schacon@gmail.com> writes:
> 
> > On Fri, Jul 25, 2008 at 4:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> ...
> >> 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 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,...
> 
> 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).

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.

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

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

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

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

Re: git-scm.com

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> 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).
>
> 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 do not think the default mode of "ls" output to tty (aka "ls -C") was
invented by/for Japanese people.

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

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.

Re: git-scm.com

[Junio C Hamano]

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

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

Re: git-scm.com

[Martin Langhoff]

On Mon, Jul 28, 2008 at 10:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 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".

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

Re: git-scm.com

[Tom Werner]

On Sun, Jul 27, 2008 at 4:19 PM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> 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.

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

Re: git-scm.com

[Johannes Schindelin]

Hi,

On Sun, 27 Jul 2008, Tom Werner wrote:

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

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.

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

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!

> Perhaps it is the commercial aspect of GitHub that offends.

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.

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

> We like to design from first principles, see how good we can do, and 
> then get feedback from the users.

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

Re: git-scm.com

[Tom Werner]

On Mon, Jul 28, 2008 at 3:50 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sun, 27 Jul 2008, Tom Werner wrote:
>> 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.
>
> 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.

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.

>> Perhaps it is the commercial aspect of GitHub that offends.
>
> 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),

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.

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

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

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

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

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.

>> We like to design from first principles, see how good we can do, and
>> then get feedback from the users.
>
> 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.

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

Re: git-scm.com

[Jon Loeliger]

Tom Werner wrote:
>
> 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. 

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

Re: git-scm.com

[Kevin Ballard]

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

> Tom Werner wrote:
>>
>> 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.
>
> 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?

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

Re: git-scm.com

[Junio C Hamano]

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

> On Sun, 27 Jul 2008, Tom Werner wrote:
>
>> 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.
>
> Speaking for myself, I will probably direct some users from #git to 
> #github, then.

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.

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

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.

Re: git-scm.com

[Martin Langhoff]

On Tue, Jul 29, 2008 at 9:42 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

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

Re: git-scm.com

[Pieter de Bie]

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Sun, 27 Jul 2008, Tom Werner wrote:
>>
>>> 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.
>>
>> Speaking for myself, I will probably direct some users from #git to
>> #github, then.
>
> 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.

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

Re: git-scm.com

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 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.
> 
> I do not talk for Shawn, but I think that comment misses the mark by a
> large margin, at least for me.

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

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.

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

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.

-- 
Shawn.

Re: git-scm.com

[Patrick Aljord]

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.

Re: git-scm.com

[Scott Chacon]

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

Re: git-scm.com

[Petr Baudis]

  Hi,

On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:
> I am more concerned about the logo at the bottom, and Petr and I are
> discussing this - I can remove the logo, but then I'd have to pay for
> this out of my pocket instead of having a small logo on the page.

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

				Petr "Pasky" Baudis

Re: git-scm.com

[david]

On Sat, 26 Jul 2008, Petr Baudis wrote:

>  Hi,
>
> On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:
>> I am more concerned about the logo at the bottom, and Petr and I are
>> discussing this - I can remove the logo, but then I'd have to pay for
>> this out of my pocket instead of having a small logo on the page.
>
>  I actually think that this is *one* reference to GitHub that is
> perfectly and 100% okay; if it is sponsoring the hosting, it deserves
> the logo, and it is fairly non-intrusive. I _am_ watching out warily
> for excessive GitHub references within the rest of the site - if only
> because I have kind of personal interest in a competitor of GitHub and
> thus don't want GitHub to get unwarranted free advertising. :-)
>
> 				Petr "Pasky" Baudis

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

Re: git-scm.com

[Scott Chacon]

On Fri, Jul 25, 2008 at 7:47 PM,  <david@lang.hm> wrote:
> On Sat, 26 Jul 2008, Petr Baudis wrote:
>
>>  Hi,
>>
>> On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:
>>>
>>> I am more concerned about the logo at the bottom, and Petr and I are
>>> discussing this - I can remove the logo, but then I'd have to pay for
>>> this out of my pocket instead of having a small logo on the page.
>>
>>  I actually think that this is *one* reference to GitHub that is
>> perfectly and 100% okay; if it is sponsoring the hosting, it deserves
>> the logo, and it is fairly non-intrusive. I _am_ watching out warily
>> for excessive GitHub references within the rest of the site - if only
>> because I have kind of personal interest in a competitor of GitHub and
>> thus don't want GitHub to get unwarranted free advertising. :-)
>>
>>                                Petr "Pasky" Baudis
>
> 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

Re: git-scm.com

[Patrick Aljord]

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

Re: git-scm.com

[Junio C Hamano]

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

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

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

Re: git-scm.com

[david]

On Fri, 25 Jul 2008, Scott Chacon wrote:

> On Fri, Jul 25, 2008 at 7:47 PM,  <david@lang.hm> wrote:
>> On Sat, 26 Jul 2008, Petr Baudis wrote:
>>
>>>  Hi,
>>>
>>> On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:
>>>>
>>>> I am more concerned about the logo at the bottom, and Petr and I are
>>>> discussing this - I can remove the logo, but then I'd have to pay for
>>>> this out of my pocket instead of having a small logo on the page.
>>>
>>>  I actually think that this is *one* reference to GitHub that is
>>> perfectly and 100% okay; if it is sponsoring the hosting, it deserves
>>> the logo, and it is fairly non-intrusive. I _am_ watching out warily
>>> for excessive GitHub references within the rest of the site - if only
>>> because I have kind of personal interest in a competitor of GitHub and
>>> thus don't want GitHub to get unwarranted free advertising. :-)
>>>
>>>                                Petr "Pasky" Baudis
>>
>> since this is a Ruby on Rails site, could the 'five links' that have been
>> bothering people be randomly selected? if every time you go to the site you
>> get a different list of projects it show how broadly git is used. it's not
>> as 'in your face' as managing to select five that cause people to say "wow,
>> they're using this", but different people will react to different sites.
>>
>> if this table gets populated by GitHub, kernel.org, and a couple other
>> sources it should be vendor independant enough (and we need a table like
>> this anyway for the 'list of projects that use git', so it serves two
>> purposes)
>>
>> David Lang
>>
>
> I would really like to have the big ones there all the time ('Linux',
> 'Ruby on Rails', 'WINE', 'X.org', etc)  Prototype and MooTools are
> pretty big in the web dev world, which a lot of people are starting to
> come from - at least Prototype should be there all the time.  For the
> rest, if we want to pool a bunch of other projects from different
> places, that would be cool, but they should be active - I don't want
> people clicking on something above the fold and getting a dead
> project.  If someone wants to help me vet a list, I'd be happy to do
> that.

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

> However, that being said, it's going to be difficult to have Github
> projects not dominate the list a bit.  The fact is that it hosts far,
> far more projects than any other single hosting service.  Just in
> fully public projects, the current stats (from the website pages) are
> something like this:
>
> kernel.org : 475
> repo.or.cz : 1,553
> gitorious   : 780
> github       : 10,560
>
> It hosts far more than that if you include private projects, too.  So,
> if we want to choose totally randomly, it's going to be at least a 5:1
> ratio between github projects and all other public hosting providers.
> If anything, statistically, the current list is conservative in it's
> links to github projects.  For me to avoid using them is artificially
> punishing them for having paid plans, which is silly.

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

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

David Lang

Re: git-scm.com

[Wincent Colaiuta]

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

> However, that being said, it's going to be difficult to have Github
> projects not dominate the list a bit.  The fact is that it hosts far,
> far more projects than any other single hosting service.  Just in
> fully public projects, the current stats (from the website pages) are
> something like this:
>
> kernel.org : 475
> repo.or.cz : 1,553
> gitorious   : 780
> github       : 10,560
>
> It hosts far more than that if you include private projects, too.  So,
> if we want to choose totally randomly, it's going to be at least a 5:1
> ratio between github projects and all other public hosting providers.


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

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

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

Cheers,
Wincent

Re: git-scm.com

[Scott Chacon]

On Sat, Jul 26, 2008 at 8:48 AM, Wincent Colaiuta <win@wincent.com> wrote:
> El 26/7/2008, a las 7:30, Scott Chacon escribió:
>
>> However, that being said, it's going to be difficult to have Github
>> projects not dominate the list a bit.  The fact is that it hosts far,
>> far more projects than any other single hosting service.  Just in
>> fully public projects, the current stats (from the website pages) are
>> something like this:
>>
>> kernel.org : 475
>> repo.or.cz : 1,553
>> gitorious   : 780
>> github       : 10,560
>>
>> It hosts far more than that if you include private projects, too.  So,
>> if we want to choose totally randomly, it's going to be at least a 5:1
>> ratio between github projects and all other public hosting providers.
>
>
> I think those numbers are pretty meaningless seeing as GitHub encourages
> people to publish "forks" of other projects. Rails, for example, has about
> 270 forks at the time of writing. If I scan the list of popular projects I
> see fork counts like 129, 105, 78 and 78 (again). Are all the forks counted
> in that figure of 10,560 that you count? How many "real" projects are hosted
> there?

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

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

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

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

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

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

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

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

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

Scott

Re: git-scm.com

[Scott Chacon]

On Sat, Jul 26, 2008 at 12:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Scott,
>
> On Sat, 26 Jul 2008, Scott Chacon wrote:
>
>> 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 :)
>
> If that applies to everybody having concerns, I would love to take you up
> on your word for it.  I will be in the bay area around 24th of October
> this year.
>
> Ciao,
> Dscho

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

Re: git-scm.com

[Johannes Schindelin]

Hi,

On Sat, 26 Jul 2008, Scott Chacon wrote:

> On Sat, Jul 26, 2008 at 12:11 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Sat, 26 Jul 2008, Scott Chacon wrote:
> >
> >> 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 :)
> >
> > If that applies to everybody having concerns, I would love to take you 
> > up on your word for it.  I will be in the bay area around 24th of 
> > October this year.
> 
> That is open to anyone that has contributed a patch to git - I at least 
> owe you a beer.

Welcome the masses:

$ git shortlog -s | wc -l
504

> Let me know when you're around.

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

Ciao,
Dscho

Re: git-scm.com

[Scott Chacon]

On Sat, Jul 26, 2008 at 12:20 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 26 Jul 2008, Scott Chacon wrote:
>
>> On Sat, Jul 26, 2008 at 12:11 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >
>> > On Sat, 26 Jul 2008, Scott Chacon wrote:
>> >
>> >> 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 :)
>> >
>> > If that applies to everybody having concerns, I would love to take you
>> > up on your word for it.  I will be in the bay area around 24th of
>> > October this year.
>>
>> That is open to anyone that has contributed a patch to git - I at least
>> owe you a beer.
>
> Welcome the masses:
>
> $ git shortlog -s | wc -l
> 504
>
>> Let me know when you're around.
>
> As I said, around 24th of October this year.
>
> Ciao,
> Dscho
>

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

Re: git-scm.com

[Junio C Hamano]

Wincent Colaiuta <win@wincent.com> writes:

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

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

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

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

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

Re: git-scm.com

[Johannes Schindelin]

Hi,

On Fri, 25 Jul 2008, Scott Chacon wrote:

> 5 links in the middle?

What 5 links in the middle?

*scrolls down*

Ah, the top-posting syndrome.

Old quote, but more valid than ever:

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

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

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

Ciao,
Dscho

Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

  Hi,

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

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

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

  Plenty of minor fixes are available for pull at

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

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

  Other non-trivial nits:

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

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

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

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

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

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

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

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

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

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

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

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

Re: Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

  Hi,

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

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

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

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

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

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

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

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

Re: Official Git Homepage change? Re: git-scm.com

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

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

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.

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

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.

Re: Official Git Homepage change? Re: git-scm.com

[Johannes Schindelin]

Hi,

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

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

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

Ciao,
Dscho

Re: Official Git Homepage change? Re: git-scm.com

[Junio C Hamano]

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

> On Fri, 25 Jul 2008, Junio C Hamano wrote:
>
>> 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.
>
> FWIW my criticism in the same direction was met with ridicule, which does 
> not let me expect much of them.

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

Re: Official Git Homepage change? Re: git-scm.com

[Johannes Schindelin]

Hi,

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

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

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

Re: Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

On Fri, Jul 25, 2008 at 09:49:42PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 25 Jul 2008, Junio C Hamano wrote:
> >
> >> It's also somewhat interesting to observe that several people I have 
> >> never heard of in the git circle are simultaneously doing new git books, 
> >> apparently never asking for much technical advice from core git people, 
> >> by the way.

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

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

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

Re: Official Git Homepage change? Re: git-scm.com

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

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

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.

Re: Official Git Homepage change? Re: git-scm.com

[Thomas Adam]

2008/7/26 Junio C Hamano <gitster@pobox.com>:
> 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

Re: Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

On Sat, Jul 26, 2008 at 09:37:01AM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> 
> >   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.
> 
> 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.

  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.

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

  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

Re: Official Git Homepage change? Re: git-scm.com

[Johannes Schindelin]

Hi,

On Sun, 27 Jul 2008, Petr Baudis wrote:

> (ii) The tone on the mailing list seems frequently unnecessarily
> harsh.

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

Re: Official Git Homepage change? Re: git-scm.com

[Sverre Rabbelier]

On Sun, Jul 27, 2008 at 17:53, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Maybe I should start my mails with "Disclaimer: I only reply to you
> because I am interested in your patch."

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

-- 
Cheers,

Sverre Rabbelier

Re: Official Git Homepage change? Re: git-scm.com

[Scott Chacon]

On Fri, Jul 25, 2008 at 9:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> .... 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...
>> ...
>>   - 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.
>
> 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.
>
>>   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...
>
> 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.
>

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

Re: Official Git Homepage change? Re: git-scm.com

[Junio C Hamano]

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

> On Fri, Jul 25, 2008 at 9:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> 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.
>> ...
>> 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.
>
> 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.

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

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

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.

Re: Official Git Homepage change? Re: git-scm.com

[Scott Chacon]

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:
> "Scott Chacon" <schacon@gmail.com> writes:
>
>> On Fri, Jul 25, 2008 at 9:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> ...
>>> 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.
>>> ...
>>> 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.
>>
>> 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.
>
> 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 ;-).
>
>> 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.
>
> 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.
>

Re: Official Git Homepage change? Re: git-scm.com

[Sverre Rabbelier]

On Sat, Jul 26, 2008 at 09:27, Scott Chacon <schacon@gmail.com> wrote:
> 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 "no_w_ top-posting" Chacon

There, fixed that for you.

-- 
Cheers,

Sverre Rabbelier

Re: Official Git Homepage change? Re: git-scm.com

[Rene Herman]

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

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

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.

Re: Official Git Homepage change? Re: git-scm.com

[Jakub Narebski]

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

> On 26-07-08 09:27, Scott Chacon wrote:
> 
> > 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.
> 
> 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 focused 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...

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

Re: Official Git Homepage change? Re: git-scm.com

[Scott Chacon]

On Sat, Jul 26, 2008 at 8:21 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Rene Herman <rene.herman@keyaccess.nl> writes:
>
>> On 26-07-08 09:27, Scott Chacon wrote:
>>
>> > 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.
>>
>> 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 focused 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...
>
> 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

Re: Official Git Homepage change? Re: git-scm.com

[Jakub Narebski]

On Sat, 26 July 2008, Scott Chacon wrote:
> On Sat, Jul 26, 2008 at 8:21 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Rene Herman <rene.herman@keyaccess.nl> writes:
>>> On 26-07-08 09:27, Scott Chacon wrote:
>>>
>>>> Perhaps it would be useful to split the mailing list into
>>>> core/contrib and support lists? [...]
>>>
>>> A git-user list would be welcomed at least by me. [...]
>>
>> 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

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

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

"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

Re: Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

On Sat, Jul 26, 2008 at 12:11:01AM -0700, Junio C Hamano wrote:
> The people who design the new features and write code should have easy
> access to the issues the users of all levels have with the software and
> the documentation (and what they find useful as well).  What I am most
> afraid of is that both "We do not bother the coders" and "We are too busy
> to answer every newbie question" mentalities would lead to a fractured
> community.

The community is already fractured! I think we actually have very tiny
fraction of the user base on the mailing list - the traffic is simply
too massive. After all we chose _our_ convenience over _users'_
convenience in making this tradeoff. Also, as I mentioned in the other
mail, it's not obvious to me whether major part of our community would
be willing to participate in any mailing list at all.

(Note that I don't want to imply that this would be inherently a Bad
Thing. Some feedback still bubbles through and we have ways like Jakub's
Git User Survey as well. Maybe the user community is by now simply too
big to make the direct cross-pollination with developers feasible.)

There was a proposal some time ago for making a web forum for Git; maybe
we were too dismissive to the suggestion. I wonder where *do* these 100k
of registered GitHubbers get their Git support now? :-)

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

Re: Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

On Fri, Jul 25, 2008 at 11:43:55PM -0700, Scott Chacon wrote:
> 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 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

Re: Official Git Homepage change? Re: git-scm.com

[Jakub Narebski]

Petr Baudis <pasky@suse.cz> writes:

> On Fri, Jul 25, 2008 at 11:43:55PM -0700, Scott Chacon wrote:
> > 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 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. :-(

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

Re: Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

On Sat, Jul 26, 2008 at 01:24:05PM -0700, Jakub Narebski wrote:
> P.S. What about http://git-scm.org/ ?

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

Re: Official Git Homepage change? Re: git-scm.com

[Jonas Fonseca]

On Sat, Jul 26, 2008 at 10:32 PM, Petr Baudis <pasky@suse.cz> wrote:
> On Sat, Jul 26, 2008 at 01:24:05PM -0700, Jakub Narebski wrote:
>> P.S. What about http://git-scm.org/ ?
>
> 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?

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

Re: Official Git Homepage change? Re: git-scm.com

[Junio C Hamano]

"Jonas Fonseca" <jonas.fonseca@gmail.com> writes:

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

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

Re: Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

On Fri, Jul 25, 2008 at 09:09:43PM -0700, Junio C Hamano wrote:
> 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.

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.

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

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.

> >   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...
> 
> Let me thank you for maintaining not just git.or.cz/ but also repo.or.cz/
> and the wiki.

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

Re: Official Git Homepage change? Re: git-scm.com

[Scott Chacon]

On Fri, Jul 25, 2008 at 6:53 PM, Petr Baudis <pasky@suse.cz> wrote:
>  Hi,
>
> On Fri, Jul 25, 2008 at 10:35:43AM -0700, Scott Chacon wrote:
>> Anyhow, I'm discussing with Petr about where we want to go from here -
>> what changes he'd like to make, etc, but I obviously value your
>> opinion as well, so please let me know what you think.  The content
>> has barely changed, it's really just a usability overhaul.  I want to
>> make sure that whatever someone is looking for (especially someone
>> new), they can find in a few clicks and a few seconds.
>
>  when the initial NIH reaction passes, I have to admit that I do rather
> like it - and it's not only because you keep mentioning how awesome I am
> in your blog post. ;-)
>
>  I wonder if all the Git users find the heading rather funny as I did,
> instead of unprofessional - but maybe we don't care about users without
> a particular sense of humor. I'm also not overly fond of the color theme
> but I'm perhaps just too heavy of a blue fan.
>
>  Plenty of minor fixes are available for pull at
>
>        git://github.com/pasky/learn-github.git
>        (http://github.com/pasky/learn-github/tree/master)

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

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

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


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

Done and pushed.

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

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

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

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

>  * There is no reference to the Wiki in the documentation, only to the
> [GitDocumentation] page; I think there should be a reference to the
> [GitFaq] page too - a lot of important points that are not obvious
> to newcomers are covered there. I'm just not sure where exactly to put
> the link.
>
>  * I would go as far as put the link to the Wiki itself to the
> navigation bar, simply since it is such a crucial resource.


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


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

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

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

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

Scott

Re: Official Git Homepage change? Re: git-scm.com

[Petr Baudis]

  Hi,

On Sat, Jul 26, 2008 at 12:07:03AM -0700, Scott Chacon wrote:
> On Fri, Jul 25, 2008 at 6:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> >  Plenty of minor fixes are available for pull at
> >
> >        git://github.com/pasky/learn-github.git
> >        (http://github.com/pasky/learn-github/tree/master)
> 
> I've pulled in all this stuff and it should be live now.

  thanks.

> >
> >  Other non-trivial nits:
> >
> >  * I'm feeling a bit uneasy about listing so many projects using Git;
> > I haven't heard about quite a few of these and I'm not sure on what
> > merit should we list projects. "Prototype" or "Liftweb" and probably
> > even "Rubinius", is that going to ring a bell for major part of visitors
> > so that they say "oh, even _those_ guys are using Git"?
> 
> Based on a conversation in the other thread, I think we should have a
> list that is suggested by the community and just have the 3 or 4 that
> are really famous (Git, Linux, RoR...) and have the rest randomly
> pulled from that list - changed every day or so.

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

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

below the list.

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

> >  * Reusing captions from command manpages in the Documentation page
> > shows nicely how awful they sometimes are. :-) This is probably something
> > to fix upstream, though.
> 
> I saw you changed some of these, I can take another pass.  I'm not
> entirely sure how useful it is to have the commands on that page, to
> tell the truth.  This may go away as the documentation page evolves.

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

> >  * Is "Git for the lazy" really unique in some regard to deserve to be
> > listed among the other resources? I think we should minimalize
> > redundancy at the documentation page, the amount of material is already
> > overwhelming and it should be obvious for the visitor which document to
> > choose based on his needs. I have similar doubts about the 37signals
> > resources.
> >
> >        In other words, "let's keep the resources orthogonal!"
> 
> I agree - I would like to pull a lot of the information in those links
> into one open-source book that is kept up by the community and hosted
> at this page.  The documentation page will change significantly as we
> try to simplify and maximize the usefulness of the page.

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

> >  * There is no reference to the Wiki in the documentation, only to the
> > [GitDocumentation] page; I think there should be a reference to the
> > [GitFaq] page too - a lot of important points that are not obvious
> > to newcomers are covered there. I'm just not sure where exactly to put
> > the link.
> >
> >  * I would go as far as put the link to the Wiki itself to the
> > navigation bar, simply since it is such a crucial resource.
> 
> 
> Perhaps I should just do this - would that cover the previous one as well?

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

> >  How does that compare with the Git user manual? Have you considered
> > collaborating on that one, or what are your reasons not to? Or are you
> > trying to do something different?
> 
> I would like to - I have personally found that invaluable in learning
> Git, but I would like it to be more digestible and I would like to add
> a lot of supporting media to it - screencasts and diagrams, to help
> people that are more visual learners. Loading up a document where the
> TOC is several pages long is intimidating and difficult to start and
> stop with.

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

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

Re: git-scm.com

[Johannes Schindelin]

Hi,

On Fri, 25 Jul 2008, Scott Chacon wrote:

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

I do not like the implication that Git eats trees.

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

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

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

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

Ciao,
Dscho

Re: git-scm.com

[Petr Baudis]

  Hi,

On Sat, Jul 26, 2008 at 04:25:16AM +0200, Johannes Schindelin wrote:
> On Fri, 25 Jul 2008, Scott Chacon wrote:
> 
> > A followup on the post I did a few days ago about Git documentation.
> > I forked Petr's git.or.cz site and put up a version that I think is a
> > bit more accessible and newbie-friendly at git-scm.com.
> 
> I do not like the implication that Git eats trees.

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

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

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

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

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

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

Re: git-scm.com

[Stephan Beyer]

Johannes Schindelin wrote:
> I do not like the implication that Git eats trees.

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


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

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: git-scm.com

[Johannes Schindelin]

Hi,

On Sat, 26 Jul 2008, Stephan Beyer wrote:

> Johannes Schindelin wrote:
> > I do not like the implication that Git eats trees.
> 
> I still like the picture, though it can hurt environmentalists.

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

Very good first impression.

Not,
Dscho

Re: git-scm.com

[Scott Chacon]

On Fri, Jul 25, 2008 at 8:07 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 26 Jul 2008, Stephan Beyer wrote:
>
>> Johannes Schindelin wrote:
>> > I do not like the implication that Git eats trees.
>>
>> I still like the picture, though it can hurt environmentalists.
>
> It's not just environmentalists.  If I put myself in the shoes of a Git
> newbie, I would get the impression that Git eats my trees, i.e. destroys
> them.
>
> Very good first impression.
>
> Not,
> Dscho
>
>

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

Scott "not top-posting" Chacon

Re: git-scm.com

[Martin Langhoff]

On Sat, Jul 26, 2008 at 4:55 PM, Scott Chacon <schacon@gmail.com> wrote:
> I was a bit concerned about using the little guy too, but I've gotten
> overall very good feedback about him - people seem to like him.  I
> think it's good to have a little bit of illustration on a page.

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



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

Re: git-scm.com

[Jakub Narebski]

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

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

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

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: git-scm.com

[Petr Baudis]

On Sat, Jul 26, 2008 at 01:03:26AM -0700, Jakub Narebski wrote:
> "Scott Chacon" <schacon@gmail.com> writes:
> 
> > A followup on the post I did a few days ago about Git documentation.
> > I forked Petr's git.or.cz site and put up a version that I think is a
> > bit more accessible and newbie-friendly at git-scm.com.  I had meant
> > to discuss this with Petr before posting it to you all, but I
> > published a blog post that got a bit more attention than I expected,
> > and I didn't want you all to think I didn't care about your opinion,
> > as some have already accused me of.
> 
> On thing I am curious about: how do you plan to have current version
> of Git in the download / last version section?  Petr Baudis uses
> custom script, which search git mailing list for "[ANNOUNCE]" posts,
> and automatically updates download / last version links.

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

Re: git-scm.com

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

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

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

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

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

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

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

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

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

   - builds the source tarball and documentation tarballs;

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

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

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

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

 * send out the release announcement message to the list.

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