General and development mailing list for Git, a distributed version control system

Scott Chacon | 5 May 2012 01:29

git-scm.com refresh

Hey everyone,

I just shipped a big update to the git-scm.com website, incorporating
tons of feedback I've gotten on the site, especially from new users,
over the years.  I think it will help new users to Git find the right
installer and get up and running easier.  I have other ideas of things
to add to it in the future, but I think this is much better than the
site that has served us well for a few years now.

Some other interesting things to note:

* There is now permanent man page hosting here, for example:
http://git-scm.com/docs/git-fsck.  You can also reference any older
version of any command: http://git-scm.com/docs/git-fsck/1.5.5

* We designed a new logo[1] - there are multiple variations available
for download on the site under the most permissive CC license for any
use.

* The Pro Git book (and all of it's translations) has been directly
incorporated into the site and has better permalinks and section
anchors.  progit.org will soon be redirecting to git-scm.com.

* Matthew McCullough has started a video series[2] for newbies and
will continue to do more developer and intermediate type videos as
well.

* There are still a few asciidoc parsing issues that we're working on
- if you find anything that's weird please report it at our issue
tracker: https://github.com/github/gitscm-next/issues

(Continue reading)

headers

Jakub Narebski | 5 May 2012 02:26

Re: git-scm.com refresh

Scott Chacon <schacon <at> gmail.com> writes:

> Hey everyone,
> 
> I just shipped a big update to the git-scm.com website, incorporating
> tons of feedback I've gotten on the site, especially from new users,
> over the years.  I think it will help new users to Git find the right
> installer and get up and running easier.  I have other ideas of things
> to add to it in the future, but I think this is much better than the
> site that has served us well for a few years now.
> 
> Some other interesting things to note:
> 
> * There is now permanent man page hosting here, for example:
> http://git-scm.com/docs/git-fsck.  You can also reference any older
> version of any command: http://git-scm.com/docs/git-fsck/1.5.5

That's very good.  Thank you very much for giving home to git manpages
online.

It would be nice for those manpages to have the title of page to be
set appropriately, e.g. for http://git-scm.com/docs/git-bisect to have
"git-bisect(1)" or "git-bisect(1) Manual Page", or even perhaps
"git-bisect(1) Manual Page - Find by binary search the change that
introduced a bug" instead of just "Git".

> 
> * We designed a new logo[1] - there are multiple variations available
> for download on the site under the most permissive CC license for any
> use.

(Continue reading)

headers

Scott Chacon | 6 May 2012 00:24

Re: git-scm.com refresh

Hey,

On Fri, May 4, 2012 at 5:26 PM, Jakub Narebski <jnareb <at> gmail.com> wrote:
>> version of any command: http://git-scm.com/docs/git-fsck/1.5.5
>
> That's very good.  Thank you very much for giving home to git manpages
> online.
>
> It would be nice for those manpages to have the title of page to be
> set appropriately, e.g. for http://git-scm.com/docs/git-bisect to have
> "git-bisect(1)" or "git-bisect(1) Manual Page", or even perhaps
> "git-bisect(1) Manual Page - Find by binary search the change that
> introduced a bug" instead of just "Git".

Good catch - I'm pushing that out in a minute.

>> * We designed a new logo[1] - there are multiple variations available
>> for download on the site under the most permissive CC license for any
>> use.
>
> IMVHO it is too similar to Bazaar logo:
>
>  http://bazaar.canonical.com/bzricons/bazaar-logo.png
>
> I like the [---] git logo, but I guess it is a bit cryptic.
>           [+++]
>

I was actually concerned with the same thing, but a) not that many
people are familiar with the Bzr logo and b) when I actually look at

(Continue reading)

headers

Josh Juran | 6 May 2012 01:20

Re: git-scm.com refresh

On May 4, 2012, at 5:26 PM, Jakub Narebski wrote:

> Scott Chacon <schacon <at> gmail.com> writes:
>
>> * We designed a new logo[1] - there are multiple variations available
>> for download on the site under the most permissive CC license for any
>> use.
>
> IMVHO it is too similar to Bazaar logo:
>
>   http://bazaar.canonical.com/bzricons/bazaar-logo.png

That's nothing compared to the similarity between the Bazaar logo and  
the MacCVS Pro logo:

http://www.maccvs.org/images/roadsign_small.gif

Josh

headers

Junio C Hamano | 5 May 2012 03:31

Re: git-scm.com refresh

Scott Chacon <schacon <at> gmail.com> writes:

> Hey everyone,
>
> I just shipped a big update to the git-scm.com website,...

Thanks.  The Reference Manual area lists "apply" in a very funny place.
It should go together with "diff", whichever section you decide to put
"diff" in.  As "diff" is listed in "Basic Snapshotting", and it will not
be able to achieve that without being able to apply its output back to the
working tree or to the index, I would suggest moving "apply" to the
section as well.

I am fairly happy about the look of the new site except for a few things
.

It seems that you are trying to advocate "staging area" as some sort of
official term.  I think "it is like a staging area" is a good phrase to
use when answering "what is the index?", but I think repeating it million
times without telling the casual readers what its official name is is
counterproductive.  Don't do that.  It will confuse these same people when
they start reading manuals.

headers

Felipe Contreras | 5 May 2012 18:47

Re: git-scm.com refresh

On Sat, May 5, 2012 at 3:31 AM, Junio C Hamano <gitster <at> pobox.com> wrote:

> It seems that you are trying to advocate "staging area" as some sort of
> official term.  I think "it is like a staging area" is a good phrase to
> use when answering "what is the index?", but I think repeating it million
> times without telling the casual readers what its official name is is
> counterproductive.  Don't do that.  It will confuse these same people when
> they start reading manuals.

I think keeping the name 'index' is what is counter-productive. I
think most users don't even need to hear the term 'index' in order to
interact with the staging area in common operations, so they won't ask
"what is the index?".

--

-- 
Felipe Contreras

headers

Scott Chacon | 6 May 2012 00:38

Re: git-scm.com refresh

Hey,

On Fri, May 4, 2012 at 6:31 PM, Junio C Hamano <gitster <at> pobox.com> wrote:
>
> Thanks.  The Reference Manual area lists "apply" in a very funny place.
> It should go together with "diff", whichever section you decide to put
> "diff" in.  As "diff" is listed in "Basic Snapshotting", and it will not
> be able to achieve that without being able to apply its output back to the
> working tree or to the index, I would suggest moving "apply" to the
> section as well.

I have to disagree.  You are thinking of 'apply' from an internals
perspective I have to assume, because I use 'diff' every single day
for all sorts of stuff ("what is modified and unstaged?", "what is
modified and staged?", "what is different between these two branches?"
etc) where I can't think of a single time I've ever used 'apply'.  In
fact, even the times when I have needed to apply a patch generated
from 'diff' I used 'patch -p1' because I know it better.  I, and most
people I would guess, almost never use 'diff' to generate patch files,
we use it to see what has changed before committing or things like
that - in general usage, it's more like an advanced 'status' honestly.

> I am fairly happy about the look of the new site except for a few things
> .
>
> It seems that you are trying to advocate "staging area" as some sort of
> official term.  I think "it is like a staging area" is a good phrase to
> use when answering "what is the index?", but I think repeating it million
> times without telling the casual readers what its official name is is
> counterproductive.  Don't do that.  It will confuse these same people when

(Continue reading)

headers

Junio C Hamano | 6 May 2012 03:39

Re: git-scm.com refresh

Scott Chacon <schacon <at> gmail.com> writes:

>> As "diff" is listed in "Basic Snapshotting", and it will not
>> be able to achieve that without being able to apply its output back to the
>> working tree or to the index, I would suggest moving "apply" to the
>> section as well.
>
> I have to disagree.  You are thinking of 'apply' from an internals
> perspective I have to assume, because I use 'diff' every single day
> for all sorts of stuff ("what is modified and unstaged?", "what is
> modified and staged?", "what is different between these two branches?"
> etc) ...

The other day when I was surfing the 'net, I found a blog that was
complaining about Git UI.  Some of the things were worth listening to, but
there was one item I really had to scratch my head where the misconception
behind the complaint came from.  I am typing from memory without bothering
to go back to the site to quote, but the complaint essentially was:

        Getting a patch is easy with "git diff", but to apply it you need
        to make it an email and feed it to "git am"???  That's crazy.

Of course it *is* crazy, if that were the case. I was wondering why the
obvious "patch" (or "git apply") did not get into the mind of the author,
and I think I now know why.

If the owner of the site that people call "git's home page" does not care
about those who take diffs and apply them as patches, and thinks "git
apply" as a mere implementation detail of "git am", it is understandable
that such a misconception is spread widely to harm users without getting

(Continue reading)

headers

Felipe Contreras | 6 May 2012 04:31

Re: git-scm.com refresh

On Sun, May 6, 2012 at 3:39 AM, Junio C Hamano <gitster <at> pobox.com> wrote:
> Scott Chacon <schacon <at> gmail.com> writes:
>
>>> As "diff" is listed in "Basic Snapshotting", and it will not
>>> be able to achieve that without being able to apply its output back to the
>>> working tree or to the index, I would suggest moving "apply" to the
>>> section as well.
>>
>> I have to disagree.  You are thinking of 'apply' from an internals
>> perspective I have to assume, because I use 'diff' every single day
>> for all sorts of stuff ("what is modified and unstaged?", "what is
>> modified and staged?", "what is different between these two branches?"
>> etc) ...
>
> The other day when I was surfing the 'net, I found a blog that was
> complaining about Git UI.  Some of the things were worth listening to, but
> there was one item I really had to scratch my head where the misconception
> behind the complaint came from.  I am typing from memory without bothering
> to go back to the site to quote, but the complaint essentially was:
>
>        Getting a patch is easy with "git diff", but to apply it you need
>        to make it an email and feed it to "git am"???  That's crazy.
>
> Of course it *is* crazy, if that were the case. I was wondering why the
> obvious "patch" (or "git apply") did not get into the mind of the author,
> and I think I now know why.
>
> If the owner of the site that people call "git's home page" does not care
> about those who take diffs and apply them as patches, and thinks "git
> apply" as a mere implementation detail of "git am", it is understandable

(Continue reading)

headers

Scott Chacon | 6 May 2012 05:51

Re: git-scm.com refresh

On Sat, May 5, 2012 at 6:39 PM, Junio C Hamano <gitster <at> pobox.com> wrote:
> Scott Chacon <schacon <at> gmail.com> writes:
>
>>> As "diff" is listed in "Basic Snapshotting", and it will not
>>> be able to achieve that without being able to apply its output back to the
>>> working tree or to the index, I would suggest moving "apply" to the
>>> section as well.
>>
>> I have to disagree.  You are thinking of 'apply' from an internals
>> perspective I have to assume, because I use 'diff' every single day
>> for all sorts of stuff ("what is modified and unstaged?", "what is
>> modified and staged?", "what is different between these two branches?"
>> etc) ...
>
> The other day when I was surfing the 'net, I found a blog that was
> complaining about Git UI.  Some of the things were worth listening to, but
> there was one item I really had to scratch my head where the misconception
> behind the complaint came from.  I am typing from memory without bothering
> to go back to the site to quote, but the complaint essentially was:
>
>        Getting a patch is easy with "git diff", but to apply it you need
>        to make it an email and feed it to "git am"???  That's crazy.
>
> Of course it *is* crazy, if that were the case. I was wondering why the
> obvious "patch" (or "git apply") did not get into the mind of the author,
> and I think I now know why.

You think he doesn't know about 'git apply' because I'm not listing it
under Basic Snapshotting in the site I put live yesterday?  Or because
I'm not teaching that?  That makes no sense, I don't understand why

(Continue reading)

headers

Philip Oakley | 6 May 2012 10:33

Re: git-scm.com refresh

From: "Junio C Hamano" <gitster <at> pobox.com> Sent: Sunday, May 06, 2012 2:39
AM
 > Scott Chacon <schacon <at> gmail.com> writes:
>
>>> As "diff" is listed in "Basic Snapshotting", and it will not
>>> be able to achieve that without being able to apply its output back to
>>> the
>>> working tree or to the index, I would suggest moving "apply" to the
>>> section as well.
>>
>> I have to disagree.  You are thinking of 'apply' from an internals
>> perspective I have to assume, because I use 'diff' every single day
>> for all sorts of stuff ("what is modified and unstaged?", "what is
>> modified and staged?", "what is different between these two branches?"
>> etc) ...
>
> The other day when I was surfing the 'net, I found a blog that was
> complaining about Git UI.  Some of the things were worth listening to, but
> there was one item I really had to scratch my head where the misconception
> behind the complaint came from.  I am typing from memory without bothering
> to go back to the site to quote, but the complaint essentially was:
>
>        Getting a patch is easy with "git diff", but to apply it you need
>        to make it an email and feed it to "git am"???  That's crazy.
>
<snip>

> "diff" pairs with "apply", and "format-patch" pairs with "am".
>
> I wouldn't mind adding "git patch" as a built-in synonym/alias for "git

(Continue reading)

headers

Junio C Hamano | 7 May 2012 19:06

Re: git-scm.com refresh

"Philip Oakley" <philipoakley <at> iee.org> writes:

> From: "Junio C Hamano" <gitster <at> pobox.com> Sent: Sunday, May 06, 2012 2:39
>
>> "diff" pairs with "apply", and "format-patch" pairs with "am".
>>
>> I wouldn't mind adding "git patch" as a built-in synonym/alias for "git
>> apply", if you think that would make the above pairing more obvious.  Many
>> computer users know what "patch" does already even they have never used
>> any SCM.
>
> Part of the problem is that the `git diff` man page [1] doesn't actively
> tell the user that its result will be in a patch format, and that such a
> patch can be `apply`ed. There are only 5 uses of 'apply' buried in the body
> text, never as a command, as if they are special cases. There is a section
> on the -p option, again it feels like it is a special case.

Sounds like you spotted a good set of places in the documentation that
need to be updated.

> The normal case of `git diff` for most users is simply as an extended 'what
> changed' git status.

I think that use of "diff" is listed in "Inspection and Comparison"
section, and I fully agree and is happy to see "diff" there as well.  Of
course, I wouldn't suggest "apply" to go next to that use of "diff".

But what I have been discussing was the use of "diff" in the "Basic
Snapshotting" section.  I actually very often use "diff" paired with
"apply" for my own work, not when working to integrate others' work.

(Continue reading)

headers

Junio C Hamano | 8 May 2012 18:51

Re: git-scm.com refresh

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

> But what I have been discussing was the use of "diff" in the "Basic
> Snapshotting" section.  I actually very often use "diff" paired with
> "apply" for my own work, not when working to integrate others' work.  
>
> Also I do not think anybody would use "apply" to accept patches (that is
> what "am" is for), so listing it in "Email" section is doubly wrong.  If
> for some reason the command Reference does not want to have "apply" next
> to "diff" listed in "Basic Snapshotting", I do not think there is any
> category on that page for the command to belong to.
>
> The above two were the primary things that triggered my reaction.
>
> When reshaping a multi-commit series, "git diff $rev1 $rev2 >P.diff"
> followed by "git apply <P.diff" (either with or without editing P.diff in
> between) is sometimes a more versatile and even more natural solution than
> repeated use of "rebase -i" is, depending on what kind of reshaping
> I want to do.
>
> For example,...  Of course this
> does not have to be "rebase" but picking only part of good infrastructure
> change from totally unrelated branch.  A concrete example is ...

I encountered another example yesterday after sending the above message
[*1*].  I was fixing one small bug, and had a commit that updates code and
adds a test vector.  It is a single commit on top of the current branch
tip, which allegedly as a buggy code.

Then I wanted to double check that the bug really existed before the fix.

(Continue reading)

headers

Andreas Schwab | 8 May 2012 19:46

Re: git-scm.com refresh

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

> I encountered another example yesterday after sending the above message
> [*1*].  I was fixing one small bug, and had a commit that updates code and
> adds a test vector.  It is a single commit on top of the current branch
> tip, which allegedly as a buggy code.
>
> Then I wanted to double check that the bug really existed before the fix.
>
> 	git checkout HEAD^
>         git show  <at> {-1} t/ | git apply

Alternative:
          git checkout  <at> {-1} t/

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

headers

Junio C Hamano | 8 May 2012 20:00

Re: git-scm.com refresh

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> Junio C Hamano <gitster <at> pobox.com> writes:
>
>> I encountered another example yesterday after sending the above message
>> [*1*].  I was fixing one small bug, and had a commit that updates code and
>> adds a test vector.  It is a single commit on top of the current branch
>> tip, which allegedly as a buggy code.
>>
>> Then I wanted to double check that the bug really existed before the fix.
>>
>> 	git checkout HEAD^
>>         git show  <at> {-1} t/ | git apply
>
> Alternative:
>           git checkout  <at> {-1} t/

True in this case, but that is usable when "diff  <at> {-1}^  <at> {-1}" happens to
be the _only_ change to your current state, so it won't be a general
substitute for the "diff | apply" pipeline.

headers

Andrew Sayers | 5 May 2012 11:14

Re: git-scm.com refresh

I had a poke round the site looking for trouble - here's what I found:

I'm using Linux, but for some reason the front page offers me downloads
for Mac.  When I click on "Mac GUIs", I am taken to a sensible URL for
Macs[1] but the button at the top says "Only show GUIs for my own OS
(Windows)".  I'm not sure how the detection works, but I have Javascript
disabled and the following user agent string:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko)
Chrome/17.0.963.56 Safari/535.11
Automatically guessing the user's OS is a good way of reducing interface
complexity, but for example the Firefox homepage[2] shows Windows, Linux
and Mac OS buttons if it can't guess.  This probably also helps Google
index their site, as GoogleBot can follow links to all the OS-specific
download pages.

The "about" section doesn't work in JS-disabled browsers - I always see
the "branching and merging" page no matter what I click on.  Again, this
means GoogleBot most likely won't index the other pages.

Not a bug, but a little tip - while investigating the issue on the
"about" page, I noticed that all the links had href="#".  You might want
to consider using href="#some-unique-identifier" so when you click round
the site with a JS-enabled browser and notice a "#" in the URL, you can
identify which click handler(s) failed.

Probably another non-JS browser issue, although not one that will bother
Google: the "book" section in the documentation page[3] has the first
"book cover" block protruding way into the left column, with all its
text mirrored.

(Continue reading)

headers

Felipe Contreras | 5 May 2012 16:01

Re: git-scm.com refresh

Hi,

On Sat, May 5, 2012 at 1:29 AM, Scott Chacon <schacon <at> gmail.com> wrote:
> * We designed a new logo[1] - there are multiple variations available
> for download on the site under the most permissive CC license for any
> use.

I don't like it. I don't see how it can possibly be related to git in
any way. There are no plus and minus anywhere, nor green :)

But anyway, if you are going to use such a logo, perhaps you should
choose a less saturated red, or even green would be better, and use
the black version as the page favicon (like in github).

See how bad it looks in my browser:
http://felipec.org/git-scm-screenshot.png

Also, the hugely saturated red on the rest of the page seems
offsetting. A less saturated red often looks bad, but a less saturated
green not so much.

And probably rotate the logo it 180 degrees; it looks like development
is going down?

Other than that I think it's great :)

Thanks!

--

-- 
Felipe Contreras

(Continue reading)

headers

Philip Oakley | 5 May 2012 16:36

Re: git-scm.com refresh

From: "Scott Chacon" <schacon <at> gmail.com>Sent: Saturday, May 05, 2012 12:29 
AM
> Hey everyone,
>
> I just shipped a big update to the git-scm.com website, incorporating
> tons of feedback I've gotten on the site, especially from new users,
> over the years.  I think it will help new users to Git find the right
> installer and get up and running easier.  I have other ideas of things
> to add to it in the future, but I think this is much better than the
> site that has served us well for a few years now.
>

I liked the groupings of the commands on the doc/reference page 
http://git-scm.com/docs (plural).
I felt they were reasonably grouped and relatively inviting to explore.

The visual cheatsheet looks interesting and informative, though wasn't what 
I was expecting from its title - perhaps "interactive cheatsheet"?
[If they did a composite with all the cheats in cascade it'd make a good 
printout]

Philip Oakley

headers

Neal Kreitzinger | 6 May 2012 02:08

Re: git-scm.com refresh

On 5/4/2012 6:29 PM, Scott Chacon wrote:
>
> I just shipped a big update to the git-scm.com website
>
I'll miss Torvald the Troll (http://torvald.gjovaag.com/)showing the 
trees of thor's woods (tor's wald) who's boss.  :(

> * There is now permanent man page hosting here

Thanks for rescuing the man!  I suppose you also had help from the ents. 
  Thanks to them too.  :)

> Let me know if you run into anything or there are any features you
> would like to see.

The new homepage looks too slick.  The hacky look of the old one was 
more in keeping with cli git.  This is git.git, not github.  ;)

v/r,
neal

headers

Neal Kreitzinger | 6 May 2012 07:10

Re: git-scm.com refresh

On 5/4/2012 6:29 PM, Scott Chacon wrote:
>
> I just shipped a big update to the git-scm.com website...
>
Thanks for the cool website, old and new!  :)

> * There is now permanent man page hosting here, for example:
> http://git-scm.com/docs/git-fsck.  You can also reference any older
> version of any command: http://git-scm.com/docs/git-fsck/1.5.5
>
IMO, I think the reference manual before the kernel.org crash was the 
best.  Back then, you first got a list of all the versions and you 
picked your version.  If I'm on version x I want to click on version x 
one time for the entire refman, not for every manpage.

I prefer the git.git make doc version of the html.  If you could have a 
'classic' view of the reference manual that would be great.  I'm not an 
expert on the make doc technologies, but if your version is harder to 
get working then a classic view would enable you to quickly and reliably 
publish updates while ironing out the enhanced version.

Also, the new format has *way* too much whitespace on the sides for the 
manpages.  (Progit also has too much whitespace -- was it like that 
before?)  The manpages are long enough without double column width in a 
single column.  ;)  The related topics is interesting.  I think this 
hybrid reference manual format should be called 'enhanced' or something. 
  I think its important to keep the official git reference manual 
clearly distinguished from supplemental material because some of the 
supplements are not correct (ie, [a]progit merge=ours).  I think the new 
hybrid format disguised as the reference manual will cause the newsgroup

(Continue reading)

headers

Matthieu Moy | 6 May 2012 13:04

Re: git-scm.com refresh

Scott Chacon <schacon <at> gmail.com> writes:

> * There is now permanent man page hosting here, for example:
> http://git-scm.com/docs/git-fsck.  You can also reference any older
> version of any command: http://git-scm.com/docs/git-fsck/1.5.5

Great.

Could somebody with kernel.org access set up redirects from
http://www.kernel.org/pub/software/scm/git/docs/* to these pages? There
are still tons of links pointing to kernel.org's 404 errors ...

Some time ago, you mentionned some plans to host a wiki on git-scm.com,
is it still the case? I noticed that the kernel.org wiki was back since
a few days, so the question is different now.

--

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

headers

Scott Chacon | 6 May 2012 15:36

Re: git-scm.com refresh

Hey,

On Sun, May 6, 2012 at 4:04 AM, Matthieu Moy
<Matthieu.Moy <at> grenoble-inp.fr> wrote:
> Great.
>
> Could somebody with kernel.org access set up redirects from
> http://www.kernel.org/pub/software/scm/git/docs/* to these pages? There
> are still tons of links pointing to kernel.org's 404 errors ...
>
> Some time ago, you mentionned some plans to host a wiki on git-scm.com,
> is it still the case? I noticed that the kernel.org wiki was back since
> a few days, so the question is different now.

I am still planning on doing this.  Since it took them several months
to get back and as you point out, while they're down links go bad all
over the place, I am planning on owning the wiki so we can have more
control over it.  I also want to make it easier to contribute to it
and have it be Git backed.  This is a project on my to-do list.

Scott

headers

Christian Couder | 7 May 2012 06:18

Re: git-scm.com refresh

Hi Scott,

On Sat, May 5, 2012 at 1:29 AM, Scott Chacon <schacon <at> gmail.com> wrote:
> Hey everyone,
>
> I just shipped a big update to the git-scm.com website, incorporating
> tons of feedback I've gotten on the site, especially from new users,
> over the years.  I think it will help new users to Git find the right
> installer and get up and running easier.  I have other ideas of things
> to add to it in the future, but I think this is much better than the
> site that has served us well for a few years now.
>
> Some other interesting things to note:
>
> * There is now permanent man page hosting here, for example:
> http://git-scm.com/docs/git-fsck.  You can also reference any older
> version of any command: http://git-scm.com/docs/git-fsck/1.5.5

Great!

> * We designed a new logo[1] - there are multiple variations available
> for download on the site under the most permissive CC license for any
> use.

I prefer the old one.

> * The Pro Git book (and all of it's translations) has been directly
> incorporated into the site and has better permalinks and section
> anchors.  progit.org will soon be redirecting to git-scm.com.

(Continue reading)

headers

Ævar Arnfjörð Bjarmason | 7 May 2012 19:08

Re: git-scm.com refresh

On Mon, May 7, 2012 at 6:18 AM, Christian Couder
<christian.couder <at> gmail.com> wrote:
> I would like the page about the git authors to be back.

I'd also like that back, it was the best done author page in any
project I've seen because it was automatically generated and regularly
updated.

headers

A Large Angry SCM | 7 May 2012 17:08

Re: git-scm.com refresh

On 05/04/2012 07:29 PM, Scott Chacon wrote:
> Hey everyone,
>
> I just shipped a big update to the git-scm.com website, incorporating
> tons of feedback I've gotten on the site, especially from new users,
> over the years.  I think it will help new users to Git find the right
> installer and get up and running easier.  I have other ideas of things
> to add to it in the future, but I think this is much better than the
> site that has served us well for a few years now.

[...]

I was looking over the updated website and what follows are my initial 
impressions:

1) I like the old logo much better.

2) I notice that GitHub is NOT listed as a company or project using git 
on the main page. What SCM does GitHub use? :-O

3) On the About -> Small and Fast Page: you show a comparison to Git and 
Git* for the clone operation but there is no explanation of how Git and 
Git* differ.

4) It's 2 clicks to get to a category view of the man pages: I think 
that's 1 too many.

5) I would like to see a page that lists all of the documentation in the 
core distribution in one place. A good place for this would be somewhere 
near the top of the category view page.

(Continue reading)

headers

Matthieu Moy | 7 May 2012 23:04

Re: git-scm.com refresh

Scott Chacon <schacon <at> gmail.com> writes:

> Let me know if you run into anything or there are any features you
> would like to see.

On http://git-scm.com/community one can see how to post and how to read
the archives of the mailing-list, but not how to subscribe. I guess you
need to add a link to http://vger.kernel.org/vger-lists.html#git

Typing "git <at> vger.kernel.org" in the search box gives no result. Probably
the search box should suggest searching an external search engine (e.g.
google, restricted to git-scm.org)

--

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

headers

Heiko Voigt | 10 May 2012 00:13

Re: git-scm.com refresh

Hi,

On Mon, May 07, 2012 at 11:04:52PM +0200, Matthieu Moy wrote:
> Scott Chacon <schacon <at> gmail.com> writes:
> 
> > Let me know if you run into anything or there are any features you
> > would like to see.
> 
> On http://git-scm.com/community one can see how to post and how to read
> the archives of the mailing-list, but not how to subscribe. I guess you
> need to add a link to http://vger.kernel.org/vger-lists.html#git

One thing I noticed is that there is no link to the msysgit project for
the windows development under community. The only way you can find it is
under download when you look closely at the text when the download is
starting.

Could we add some information about msysgit for windows development on
the community page?

Maybe the same applies for other OS like the osx installer?

Cheers Heiko

headers

Antonio Ospite | 8 May 2012 14:29

Re: git-scm.com refresh

Scott Chacon <schacon <at> gmail.com> writes:

> 
> Hey everyone,
> 
> I just shipped a big update to the git-scm.com website, incorporating
> tons of feedback I've gotten on the site, especially from new users,
> over the years.  I think it will help new users to Git find the right
> installer and get up and running easier.  I have other ideas of things
> to add to it in the future, but I think this is much better than the
> site that has served us well for a few years now.
> 
> Some other interesting things to note:
> 
> * There is now permanent man page hosting here, for example:
> http://git-scm.com/docs/git-fsck.  You can also reference any older
> version of any command: http://git-scm.com/docs/git-fsck/1.5.5
>

Some pages are not displayed correctly:
http://git-scm.com/docs/git-rebase for instance gets corrupted at some point.

> * We designed a new logo[1] - there are multiple variations available
> for download on the site under the most permissive CC license for any
> use.
> 

FWIW I also miss the + and - in the logo but I think I will survive :)

Thanks,

(Continue reading)