From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:25
Petr Baudis [off-list ref] writes:
I'm personally not exceptionally fond of wikis (other than Wikipedia)
but a wish to have one has been expressed several times and I hope it
will be helpful for the Git community; not only the newbies might dig
(and especially exchange!) some useful information, tips'n'trick and
such. Ideally, it could become a melting pot for the Documentation/
directories or the rather austere (I take patches) Git homepage - or
something entirely different. Whatever _you_ make from it.
Thanks for doing this. I am not a Wiki person myself, and
would rather want to see we have useful and authoritative bits
in the Documentation set, but this would help the community.
I'd love to see somebody volunteer to act as an editor to feed
cooked topics for inclusion of the Documentation/ set. Anybody?
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:42:25
On 5/3/06, Junio C Hamano [off-list ref] wrote:
Petr Baudis [off-list ref] writes:
quoted
I'm personally not exceptionally fond of wikis (other than Wikipedia)
but a wish to have one has been expressed several times and I hope it
will be helpful for the Git community; not only the newbies might dig
(and especially exchange!) some useful information, tips'n'trick and
such. Ideally, it could become a melting pot for the Documentation/
directories or the rather austere (I take patches) Git homepage - or
something entirely different. Whatever _you_ make from it.
Thanks for doing this. I am not a Wiki person myself, and
would rather want to see we have useful and authoritative bits
in the Documentation set, but this would help the community.
I'd love to see somebody volunteer to act as an editor to feed
cooked topics for inclusion of the Documentation/ set. Anybody?
BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
(they choose Mercurial).
I think it's explained somewhere in their forums (or mailing lists or
whatever they actually _are_).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
The final evaluations are available from here (at the very bottom
of the page):
http://opensolaris.org/os/community/tools/scm/
It looks like Mercurial doesn't support renames either, but a lot
of users are asking for it to be supported. So I don't think that's
the reason. It looks more like they didn't enjoy porting GIT 1.2.2
(as 1.2.4 was found to not work in all cases) to Solaris and the
tester ran into some problems with the conflict resolution support.
My own reading of the two final evaluations for GIT and Mercurial
leaves me feeling like GIT is a more mature tool which is faster
and more stable then Mercurial. GIT seemed to be more reliable
during testing then Mercurial was, despite the cloning issue.
Which makes me surprised that OpenSolaris selected Mercurial instead.
--
Shawn.
The final evaluations are available from here (at the very bottom
of the page):
http://opensolaris.org/os/community/tools/scm/
It looks like Mercurial doesn't support renames either, but a lot
of users are asking for it to be supported. So I don't think that's
the reason. It looks more like they didn't enjoy porting GIT 1.2.2
(as 1.2.4 was found to not work in all cases) to Solaris and the
tester ran into some problems with the conflict resolution support.
My own reading of the two final evaluations for GIT and Mercurial
leaves me feeling like GIT is a more mature tool which is faster
and more stable then Mercurial. GIT seemed to be more reliable
during testing then Mercurial was, despite the cloning issue.
Which makes me surprised that OpenSolaris selected Mercurial instead.
Considering Sun's CEO's common comments on Solaris' superiority over
Linux I think it's safe to assume that the same CEO wouldn't exactly
jump of joy if his employees started depending on a tool fathered by Linus.
No offence intended to Mercurial or its developers. Although I don't
know anything about how it works I'm fairly sure Sun's developers would
never agree to be forced to use an inferior tool (congrats Mercurial
devs). However, I *do* think that in a tie-break Mercurial would win for
political reasons.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
The final evaluations are available from here (at the very bottom
of the page):
http://opensolaris.org/os/community/tools/scm/
It looks like Mercurial doesn't support renames either, but a lot
of users are asking for it to be supported. So I don't think that's
the reason. It looks more like they didn't enjoy porting GIT 1.2.2
(as 1.2.4 was found to not work in all cases) to Solaris and the
tester ran into some problems with the conflict resolution support.
My own reading of the two final evaluations for GIT and Mercurial
leaves me feeling like GIT is a more mature tool which is faster
and more stable then Mercurial. GIT seemed to be more reliable
during testing then Mercurial was, despite the cloning issue.
Which makes me surprised that OpenSolaris selected Mercurial instead.
Would be fantastic to see a fair comparison of the two tools but I
can't find anything useful on the web.
--
Paolo
http://paolociarrocchi.googlepages.com
Considering Sun's CEO's common comments on Solaris' superiority over Linux I
think it's safe to assume that the same CEO wouldn't exactly jump of joy if
his employees started depending on a tool fathered by Linus.
I doubt it went that high up, but with any kind of politics it's obviously
possible that somebody consciously or unconsciously felt it might become a
political problem, and it might have made a difference.
However, I think the _real_ issue is that Mercurial has a much nicer
introductory phase. The standard mercurial web-page is so much more
professional and nice to look at than any git page I have ever seen, and
let's face it: first looks _do_ count.
Also, the fact that Solaris had the unfortunate bug with signals probably
didn't much help to endear git to them, since it made it look like git had
problems. Never mind that we solved it - I think it took us a while to
even realize that Solaris had a problem, because we weren't intimately
involved.
Which brings me to the final point, which is that I think the hg team was
very active and supporting, perhaps Matt himself. That's _important_ - the
OpenSolaris people probably felt very comfortable with strong support from
the developers. It can often be _the_ best (and biggest) reason to choose
any product - regardless of anything else.
Even if I think the git mailing list itself is very responsive, I think
the hg people were just more directly and actively involved. For git, they
had to come to us.
I also suspect that some people find python scripts somewhat less
intimidating than C. I'll also happily admit that my coding standards tend
to lean towards the "sparse" when it comes to comments, and I much prefer
the "small and well-named functions" approach, and git seems to have stuck
to that with Junio. Which just turns some people off.
So I don't think you need politics to explain it. I think hg is doing
quite well. It took some different design decisions, and while I
personally think the git ones are better, I'm somewhat biased ;)
Linus
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:42:25
On 5/3/06, Linus Torvalds [off-list ref] wrote:
On Wed, 3 May 2006, Andreas Ericsson wrote:
quoted
Considering Sun's CEO's common comments on Solaris' superiority over Linux I
think it's safe to assume that the same CEO wouldn't exactly jump of joy if
his employees started depending on a tool fathered by Linus.
I doubt it went that high up, but with any kind of politics it's obviously
possible that somebody consciously or unconsciously felt it might become a
political problem, and it might have made a difference.
However, I think the _real_ issue is that Mercurial has a much nicer
introductory phase. The standard mercurial web-page is so much more
professional and nice to look at than any git page I have ever seen, and
let's face it: first looks _do_ count.
I can only agree.
I'm not a git developer, I'm even not a _real_ developer, I only hack
for fun during my very poor spare time but web pages, wiki and
introduction offered by Mercurial are really a lot nicer to what git
is offering at the moment.
Perhaps is just a silly idea, but would be possible for OSDL to host a
web site (www.git.org) where we can host pages/wiki an so on?
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
Perhaps is just a silly idea, but would be possible for OSDL to host a
web site (www.git.org) where we can host pages/wiki an so on?
I don't think hosting it would be a problem (it probably would be the same
kernel.org thing - OSDL is partly involved in maintaining it). The problem
is the content, and the artistic talent.
_I_ personally have what I'd call "negative artistic talent". I think I'm
occasionally good at designing beautiful data structures (and I think git
is that, including the pack-files), but that clearly doesn't translate to
any visual ability what-so-ever. None. Nada. Zilch.
Maybe the new Wiki can evolve into that. It sure looks better today than
it looked yesterday (now, when I first saw it, it was so ugly that I had
to dig my eyeballs out with a spoon, so that's not necessarily saying all
that much ;)
Linus
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:25
Linus Torvalds wrote:
On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
quoted
Perhaps is just a silly idea, but would be possible for OSDL to host a
web site (www.git.org) where we can host pages/wiki an so on?
I don't think hosting it would be a problem (it probably would be the same
kernel.org thing - OSDL is partly involved in maintaining it). The problem
is the content, and the artistic talent.
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating of
course what is in official Git Documentation/
--
Jakub Narebski
Warsaw, Poland
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:42:25
On 5/3/06, Jakub Narebski [off-list ref] wrote:
Linus Torvalds wrote:
quoted
On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
quoted
Perhaps is just a silly idea, but would be possible for OSDL to host a
web site (www.git.org) where we can host pages/wiki an so on?
I don't think hosting it would be a problem (it probably would be the same
kernel.org thing - OSDL is partly involved in maintaining it). The problem
is the content, and the artistic talent.
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating of
course what is in official Git Documentation/
I just added the TODO list link but I'm not a wiki expert, if you know
how to link to the article from Wikipedia please do it ;-)
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:25
Paolo Ciarrocchi wrote:
On 5/3/06, Jakub Narebski [off-list ref] wrote:
quoted
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating
of course what is in official Git Documentation/
I just added the TODO list link but I'm not a wiki expert, if you know
how to link to the article from Wikipedia please do it ;-)
I thought about copying contents, not making a link to WikiPedia article.
I tried to make InterWiki link, WikiPedia:Git_(software) but MoinMoin engine
doesn't deal well with parentheses.
--
Jakub Narebski
Warsaw, Poland
Mercurial also has an easier learning curve; and while the "Everyday
Git with 20 commands or so" is a very good document, and I've found it
invaluable for getting started, if you compare it to the "Quick Start
for the Impatient" page on the front page of the Mercurial Wiki, for
many people Mercurial will *appear* to be an order of magitude simpler
and is yet powerful enough for their project.
Of course, a lot of it is that git *is* much more powerful, much like
the difference between a stickshift with a racing clutch (git) and a
car with an automatic transmission (hg). So maybe one thing that
would help git would be a stronger emphasis of cogito for those
projects that don't need the full power of using git "straight up".
Just a thought....
- Ted
Of course, a lot of it is that git *is* much more powerful, much like
the difference between a stickshift with a racing clutch (git) and a
car with an automatic transmission (hg).
I don't think that's necessarily a good comparison.
The "easy things" are easy even with git. Our explanation pages and
tutorials just tend to want to show off, and do more than they need to.
Even the "everyday git in 20 commands" actually starts out scaring people
with listing commands that they don't need to know about immediately. The
whole fsck/count-object/pruning thing shouldn't even be mentioned until
after you've shown how easy it is to just do
git init-db
git add .
git commit -a
to import an old project, and then do an example commit or something
(one of the early examples).
So yeah. We should have a main page that starts off with the "everyday
git" link (preferably further simplified) very prominently, and just looks
less scary.
People are probably already expecting the worst - partly because git is
newer than some of the other projects (not hg, but svn/svk/monotone etc),
and partly because I was actively trying to not over-promise or over-sell
early on when it wasn't clear how good git was going to get..
So looking pretty and easy to use is clearly important, and I think git
has the _capability_ for that, we've not just documented it that way.
Linus
On Wed, May 03, 2006 at 10:06:25AM -0700, Linus Torvalds wrote:
Even the "everyday git in 20 commands" actually starts out scaring people
with listing commands that they don't need to know about immediately. The
whole fsck/count-object/pruning thing shouldn't even be mentioned until
after you've shown how easy it is to just do
git init-db
git add .
git commit -a
to import an old project, and then do an example commit or something
(one of the early examples).
Yeah, but the fact that you have to use repack and prune in order to
keep the disk space usage from exploding (especially with the Linux
2.6 tree) , means that we have to expose that mess to the beginning
user. Could git be made to do the repacking automatically when it
makes sense using some hueristic algorithm?
- Ted
Yeah, but the fact that you have to use repack and prune in order to
keep the disk space usage from exploding (especially with the Linux
2.6 tree) , means that we have to expose that mess to the beginning
user.
No you don't. You get it packed when it's cloned, and the disk usage
doesn't go up _that_ fast. By the time you need to worry about disk usage
you have certainly had time to learn the basics.
No need to start talking about fsck or repacking until the second day.
Could git be made to do the repacking automatically when it makes sense
using some hueristic algorithm?
This was discussed, and yeah, it _could_, but I suspect you really don't
want to repack in the middle of some op. Even if your repo was _mostly_
packed, it's an irritating hickup at a time when you don't need to.
I think it's much better to teach people to repack once a week (if that).
But to teach them only after they've already _used_ it for a week and
aren't intimidated by the basic ops any longer.
Linus
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:25
On Wed, 3 May 2006, Theodore Tso wrote:
Mercurial also has an easier learning curve; and while the "Everyday
Git with 20 commands or so" is a very good document, and I've found it
invaluable for getting started, if you compare it to the "Quick Start
for the Impatient" page on the front page of the Mercurial Wiki, for
many people Mercurial will *appear* to be an order of magitude simpler
and is yet powerful enough for their project.
Actually, we could almost steal their QuickStart, replace "hg" with "git",
and have it actually be correct.
Setting up public access follows a slightly different pattern, but
otherwise, all of the operations on that page are identical or simpler in
git than as given in that document, AFAICT.
-Daniel
*This .sig left intentionally blank*
On Wed, 3 May 2006 12:47:32 -0400
Theodore Tso [off-list ref] wrote:
Of course, a lot of it is that git *is* much more powerful, much like
the difference between a stickshift with a racing clutch (git) and a
car with an automatic transmission (hg). So maybe one thing that
would help git would be a stronger emphasis of cogito for those
projects that don't need the full power of using git "straight up".
The docs and higher-level user commands can still use some work, but
telling people they have to install and learn an entire extra layer
isn't going to win many converts. Personally I think Git needs a bit
more polish and to stop thinking of itself as mostly plumbing. Even so
Git really has become pretty good at making simple things simple:
init-db, add/rm, commit -a,
status, show, log, gitk, diff,
branch, checkout, clone, fetch/pull
The fact that it's faster, requires less disk space, and has all the
lower level tools you need to do "complex stuff", should make it a
tempting choice once the remaining rough edges are removed.
But there is nothing inherently complex about Git.
Sean
From: David Lang <hidden> Date: 2016-06-15 22:42:25
On Wed, 3 May 2006, Jakub Narebski wrote:
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating of
course what is in official Git Documentation/
please go ahead and put a lot of the info that is in the GIT
Documentation/ on the wiki. it's far easier to go to one site and browse
around to find things then to run into issues where you have to go
somewhere else (with different tools) to find the info.
even if you just put all the documentation files there, as-is (as text
files even, no hyperlinks in them) they should still be there.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:25
Dear diary, on Wed, May 03, 2006 at 09:21:54PM CEST, I got a letter
where David Lang [off-list ref] said that...
On Wed, 3 May 2006, Jakub Narebski wrote:
quoted
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating of
course what is in official Git Documentation/
please go ahead and put a lot of the info that is in the GIT
Documentation/ on the wiki. it's far easier to go to one site and browse
around to find things then to run into issues where you have to go
somewhere else (with different tools) to find the info.
even if you just put all the documentation files there, as-is (as text
files even, no hyperlinks in them) they should still be there.
Then who will keep it in sync (BOTH ways)? That would be quite a lot of
work, I think.
That said, having the documentation in a wiki is not a bad idea per se,
but you need to keep things consistent and converging. And I believe
(and hope) that killing Documentation/ directory is no option - I hate
it when documentation of software I installed just tells me "look at
this URI" (which documents a different version anyway, and it's all very
useful when I'm sitting in a train with my notebook).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
From: David Lang <hidden> Date: 2016-06-15 22:42:25
On Wed, 3 May 2006, Petr Baudis wrote:
Dear diary, on Wed, May 03, 2006 at 09:21:54PM CEST, I got a letter
where David Lang [off-list ref] said that...
quoted
On Wed, 3 May 2006, Jakub Narebski wrote:
quoted
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating of
course what is in official Git Documentation/
please go ahead and put a lot of the info that is in the GIT
Documentation/ on the wiki. it's far easier to go to one site and browse
around to find things then to run into issues where you have to go
somewhere else (with different tools) to find the info.
even if you just put all the documentation files there, as-is (as text
files even, no hyperlinks in them) they should still be there.
Then who will keep it in sync (BOTH ways)? That would be quite a lot of
work, I think.
That said, having the documentation in a wiki is not a bad idea per se,
but you need to keep things consistent and converging. And I believe
(and hope) that killing Documentation/ directory is no option - I hate
it when documentation of software I installed just tells me "look at
this URI" (which documents a different version anyway, and it's all very
useful when I'm sitting in a train with my notebook).
I agree with this completely.
as for keeping it in sync, the ideal situation would be for a
documentation manager to take that job ;-) but lacking that just put the
documentation in a non-editable page somewhere and link to it from the
wiki (this could even be pages at kernel.org or wherever you have the raw
source available outside of git itself)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:25
Dear diary, on Wed, May 03, 2006 at 09:46:33PM CEST, I got a letter
where David Lang [off-list ref] said that...
as for keeping it in sync, the ideal situation would be for a
documentation manager to take that job ;-) but lacking that just put the
documentation in a non-editable page somewhere and link to it from the
wiki (this could even be pages at kernel.org or wherever you have the raw
source available outside of git itself)
From: Sam Ravnborg <hidden> Date: 2016-06-15 22:42:25
On Wed, May 03, 2006 at 10:06:25AM -0700, Linus Torvalds wrote:
Even the "everyday git in 20 commands" actually starts out scaring people
with listing commands that they don't need to know about immediately.
20 commands is much more than I use in my daily use of git.
Lets see:
git clone
git diff
git reset --hard
git ls-files
git grep
git add
git rm
cg-commit
cg-restore
git push
git am
I may have missed one or two - but this is it. Lees then 20.
And I never use pack or fsck.
It is not that difficult. A few cogito commands creeped in also. I just
find them easier to use.
In other words - the tutorials are covering too much as stated by
others.
Sam
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:25
Dear diary, on Thu, May 04, 2006 at 12:39:32AM CEST, I got a letter
where Sam Ravnborg [off-list ref] said that...
20 commands is much more than I use in my daily use of git.
Lets see:
git clone
git diff
git reset --hard
git ls-files
git grep
git add
git rm
cg-commit
cg-restore
git push
git am
I think git ls-files isn't used directly very frequently. OTOH, you
don't use cg-log or git log and cg-status/git status? :) Also, most
people will pull.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
From: Joel Becker <hidden> Date: 2016-06-15 22:42:25
On Thu, May 04, 2006 at 12:46:45AM +0200, Petr Baudis wrote:
I think git ls-files isn't used directly very frequently. OTOH, you
don't use cg-log or git log and cg-status/git status? :) Also, most
people will pull.
I use git ls-files, becuase it's the only way I know how to
blow away dirty state that added files. I ran into this just yesterday,
actually. git checkout -f won't remove files that are unknown.
$ git ls-files -o | xargs rm -rf
Joel
--
Life's Little Instruction Book #452
"Never compromise your integrity."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:25
Dear diary, on Thu, May 04, 2006 at 12:50:56AM CEST, I got a letter
where Joel Becker [off-list ref] said that...
On Thu, May 04, 2006 at 12:46:45AM +0200, Petr Baudis wrote:
quoted
I think git ls-files isn't used directly very frequently. OTOH, you
don't use cg-log or git log and cg-status/git status? :) Also, most
people will pull.
I use git ls-files, becuase it's the only way I know how to
blow away dirty state that added files. I ran into this just yesterday,
actually. git checkout -f won't remove files that are unknown.
$ git ls-files -o | xargs rm -rf
You can use cg-clean, and I think Git has got git-clean added recently.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:25
Dear diary, on Wed, May 03, 2006 at 05:30:26PM CEST, I got a letter
where Linus Torvalds [off-list ref] said that...
However, I think the _real_ issue is that Mercurial has a much nicer
introductory phase. The standard mercurial web-page is so much more
professional and nice to look at than any git page I have ever seen, and
let's face it: first looks _do_ count.
Yes, I've already learned earlier that this made quite a bad impression
on many people and had the homepage revamp on top of my TODO list for
the last few weeks.
Well, here we go, I've just uploaded a new version of the Git homepage;
I wonder how you feel about it now.
Obviously, it still feels rather empty and I'm certainly not much of
a webmaster myself, but I take patches and pull requests; see
http://git.or.cz/community.html for the Git homepage git repository
information.
I've borrowed Jonas Fonseca's ELinks homepage design first, but the
contents ended up almost entirely rewritten as well (except the Related
Tools section, which stayed mostly as it was). Git now poses as a real
version control system and the plumbing stuff is mentioned only in the
bottom paragraphs. ;-)
BTW, if anyone is into CSS and stuff, after half an hour of beating it
I couldn't manage to make the top bar look right - everything is shifted
slightly to the top. :/
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:25
On Wed, 3 May 2006, Petr Baudis wrote:
Dear diary, on Wed, May 03, 2006 at 09:21:54PM CEST, I got a letter
where David Lang [off-list ref] said that...
quoted
On Wed, 3 May 2006, Jakub Narebski wrote:
quoted
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating of
course what is in official Git Documentation/
please go ahead and put a lot of the info that is in the GIT
Documentation/ on the wiki. it's far easier to go to one site and browse
around to find things then to run into issues where you have to go
somewhere else (with different tools) to find the info.
even if you just put all the documentation files there, as-is (as text
files even, no hyperlinks in them) they should still be there.
Then who will keep it in sync (BOTH ways)? That would be quite a lot of
work, I think.
That said, having the documentation in a wiki is not a bad idea per se,
but you need to keep things consistent and converging. And I believe
(and hope) that killing Documentation/ directory is no option - I hate
it when documentation of software I installed just tells me "look at
this URI" (which documents a different version anyway, and it's all very
useful when I'm sitting in a train with my notebook).
Clearly the solution is a wiki with a git backend and asciidoc for the
formatting language. Then the wiki just has to pull from kernel.org
occasionally, and Junio can pull from the wiki's repository when there are
good changes there.
I'm actually only somewhat joking; I wrote a Python CGI for this at one
point, and got as far as having it basically work, but then I couldn't
come up with a way to safely use asciidoc to format an attacker's file.
-Daniel
*This .sig left intentionally blank*
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:25
Petr Baudis wrote:
Well, here we go, I've just uploaded a new version of the Git homepage;
I wonder how you feel about it now.
Obviously, it still feels rather empty and I'm certainly not much of
a webmaster myself, but I take patches and pull requests; see
http://git.or.cz/community.html for the Git homepage git repository
information.
I've borrowed Jonas Fonseca's ELinks homepage design first, but the
contents ended up almost entirely rewritten as well (except the Related
Tools section, which stayed mostly as it was). Git now poses as a real
version control system and the plumbing stuff is mentioned only in the
bottom paragraphs. ;-)
Very nice, although earlier version had the advantage of having everything
on one page. I hope that no information was lost.
What it lacks is the link in menu bar to Home (or News),
i.e. http://git.or.cz/ or http://git.or.cz/index.html page.
About Download page (http://git.or.cz/download.html) - it would be nice to
have in comments about firewalls told which port git uses for git://
protocol.
--
Jakub Narebski
Warsaw, Poland
You could get there clicking on the Git logo, but I agree that this
wasn't very intuitive. I've added a link.
About Download page (http://git.or.cz/download.html) - it would be nice to
have in comments about firewalls told which port git uses for git://
protocol.
Good idea, added.
By the way, it has been suggested on #git that it might be worth sharing
the same color scheme between gitweb and the homepage. I have tried it
out but the gitweb's color scheme might be a bit too dull for the
homepage, dunno (I might also just already get too used to the bluish
theme). Opinions welcome. It's the "Gitweb gray" stylesheet (in Firefox,
View -> Page style).
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.