* Re: [ANNOUNCE] Git wiki
From: Petr Baudis @ 2006-05-03 19:30 UTC (permalink / raw)
To: David Lang; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.62.0605031218570.12716@qynat.qvtvafvgr.pbz>
Dear diary, on Wed, May 03, 2006 at 09:21:54PM CEST, I got a letter
where David Lang <dlang@digitalinsight.com> said that...
> 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.
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.
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: David Lang @ 2006-05-03 19:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3al00$1dj$1@sea.gmane.org>
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
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-05-03 18:54 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
- Documentation cleanups (Sean Estabrooks)
- git-format-patch uses rfc2822 compliant date (Huw Davies).
- git-am usability fixes (Robert Shearman and me)
- Fix filename verification when in a subdirectory (Linus)
- git-send-email debuggability improvements (Martin Langhoff)
- annotate fixes (Matthias Kestenholz)
- rebase: typofix.
- commit-tree.c: check_valid() microoptimization.
- verify-pack: check integrity in a saner order.
* The 'master' branch has these since the last announcement, in
addition to the above fixes.
- gitk views and highlights enhancements (Paul Mackerras).
- repo-config -l (Petr Baudis and Johannes Schindelin)
- repo-config white-space fix (Johannes Schindelin)
- diff --stat fix.
- revision parsing more strictly checks "rev -- paths"
- t0000-basic: more commit-tree tests.
- Extended SHA1 -- "rev^@" syntax to mean "all parents"
- Fix "git help -a" terminal autosizing (Linus)
- git-fetch: resolve remote symrefs for HTTP transport (Nick Hengeveld)
- daemon: socksetup: don't return on set_reuse_addr() error (Serge E. Hallyn)
* The 'next' branch, in addition, has these.
- built-in git-count-objects
- built-in git-diff.
- built-in git-push (Linus with fix by Johannes Schindelin).
- built-in git-log.
- built-in git-grep.
These not only implement them built-in, but remove the
corresponding shell script versions. I think all of them are
ready to be pushed out, so expect them soon in your "master"
branch ;-).
- repo-config: support --get-regexp (Johannes Schindelin)
- core.prefersymlinkrefs: use symlinks for .git/HEAD
- get_sha1(): :path and :[0-3]:path to extract from index.
Needs a bit more testing.
- further diff-delta improvements (Nicolas Pitre)
Benchmark impressions are welcome on this.
- cache-tree optimization
This yields a nice speedup to (apply then write-tree)+
sequence, but is rather intrusive and risky (if somebody
forgets to invalidate a cached information the next write
tree can write out corrupt data). I am hoping we can redo
this inside the index.
- built-in git-fmt-patch
This is not ready as format-patch replacement yet; it only
does --stdout.
* The 'pu' branch, in addition, has these.
- read-tree: --prefix=<path> option.
- write-tree: --exclude=<prefix>
- write-tree: --prefix=<path>
These were originally done as part of "bind commit" series,
but are useful outside the context of subproject support.
read-tree --prefix=<path> allows you to graft a tree object
at a subdirectory in an already populated index, and
write-tree --prefix=<path> allows you to write out only a
subdirectory out of an index as a tree object. I am not in
an urgent need for these features, but if some Porcelain
finds them useful, they can be merged to "next".
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: sean @ 2006-05-03 18:45 UTC (permalink / raw)
To: Theodore Tso
Cc: torvalds, ae, spearce, nico, paolo.ciarrocchi, pasky, junkio, git
In-Reply-To: <20060503164732.GB9820@thunk.org>
On Wed, 3 May 2006 12:47:32 -0400
Theodore Tso <tytso@mit.edu> 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
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Daniel Barkalow @ 2006-05-03 18:04 UTC (permalink / raw)
To: Theodore Tso
Cc: Linus Torvalds, Andreas Ericsson, Shawn Pearce, Nicolas Pitre,
Paolo Ciarrocchi, Petr Baudis, Junio C Hamano, git
In-Reply-To: <20060503164732.GB9820@thunk.org>
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*
^ permalink raw reply
* Re: git-unpack-objects
From: Linus Torvalds @ 2006-05-03 17:56 UTC (permalink / raw)
To: Josh Boyer; +Cc: Junio C Hamano, git
In-Reply-To: <625fc13d0605031044y2ff03ed2h261db5455b234254@mail.gmail.com>
On Wed, 3 May 2006, Josh Boyer wrote:
> >
> > That's what you just do "git repack -a -d" for.
>
> But that doesn't roll exsisting packs into a new pack, does it?
It does. That's what the "-a" (for "all") does.
I don't personally do incremental packs at all - the full repack is fast
enough on the hardware I use (especially since Junio just kicked it into
some serious performance shape) that I don't have the need for
incrementals.
Linus
^ permalink raw reply
* git-feed-mail-list.sh
From: David Woodhouse @ 2006-05-03 17:48 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
I've just updated the script which feeds the
git-commits-{head,24}@vger.kernel.org lists -- it now looks like this...
- Git-only; no longer uses cg-*
- No longer uses its own clone repo -- works directly from the original
- Handles MIME encoding of Subject: headers when necessary
(although this is a bit icky in shell; especially _my_ shell).
Should I be using git-format-patch for this?
--
dwmw2
[-- Attachment #2: Type: application/x-shellscript, Size: 4204 bytes --]
^ permalink raw reply
* Re: git-unpack-objects
From: Josh Boyer @ 2006-05-03 17:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605031041150.4086@g5.osdl.org>
On 5/3/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Wed, 3 May 2006, Josh Boyer wrote:
> >
> > Hm.. so it seems that git-unpack-objects is more intended to unpack a
> > pack one has gotten with git-fetch-pack, right?
>
> Yeah. And for testing. I don't think it ever gets used directly.
>
> > I was looking for something more along the lines of an
> > "un-git-repack", where you have existing pack(s) and want to undo
> > them. Maybe you want to repack everything into a single pack or
> > something like that.
>
> That's what you just do "git repack -a -d" for.
But that doesn't roll exsisting packs into a new pack, does it? I
thought it just packed loose objects into a new pack and deleted them.
I ran that on a repo that already had a couple packs in it, and the
old packs were still there.
josh
^ permalink raw reply
* Re: git-unpack-objects
From: Linus Torvalds @ 2006-05-03 17:41 UTC (permalink / raw)
To: Josh Boyer; +Cc: Junio C Hamano, git
In-Reply-To: <625fc13d0605031035l721ab08dmee6f870abb49f4e4@mail.gmail.com>
On Wed, 3 May 2006, Josh Boyer wrote:
>
> Hm.. so it seems that git-unpack-objects is more intended to unpack a
> pack one has gotten with git-fetch-pack, right?
Yeah. And for testing. I don't think it ever gets used directly.
> I was looking for something more along the lines of an
> "un-git-repack", where you have existing pack(s) and want to undo
> them. Maybe you want to repack everything into a single pack or
> something like that.
That's what you just do "git repack -a -d" for.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 17:40 UTC (permalink / raw)
To: Theodore Tso
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi,
Petr Baudis, Junio C Hamano, git
In-Reply-To: <20060503171538.GC9820@thunk.org>
On Wed, 3 May 2006, Theodore Tso wrote:
>
> 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
^ permalink raw reply
* Re: git-unpack-objects
From: Josh Boyer @ 2006-05-03 17:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu089qr4t.fsf@assigned-by-dhcp.cox.net>
On 5/1/06, Junio C Hamano <junkio@cox.net> wrote:
>
> unpack tries to unpack and if it already has the object it
> skips.
>
> If you really wanted to do it, here is a way to do so.
>
> mv .git/objets/pack/pack-49*.pack \
> .git/objets/pack/pack-49*.idx .
> git unpack-objects <pack-49*.pack
Hm.. so it seems that git-unpack-objects is more intended to unpack a
pack one has gotten with git-fetch-pack, right?
I was looking for something more along the lines of an
"un-git-repack", where you have existing pack(s) and want to undo
them. Maybe you want to repack everything into a single pack or
something like that.
josh
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Theodore Tso @ 2006-05-03 17:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi,
Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030958370.4086@g5.osdl.org>
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
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 17:06 UTC (permalink / raw)
To: Theodore Tso
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi,
Petr Baudis, Junio C Hamano, git
In-Reply-To: <20060503164732.GB9820@thunk.org>
On Wed, 3 May 2006, Theodore Tso 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).
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
^ permalink raw reply
* Re: gitk highlight feature
From: Linus Torvalds @ 2006-05-03 16:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17496.7073.507895.484698@cargo.ozlabs.ibm.com>
On Wed, 3 May 2006, Paul Mackerras wrote:
>
> Linus Torvalds writes:
>
> > The obvious way to do it would be to just have two buttons per view: one
> > exclusive one (for the main view - only one selected at a time), and the
> > other one for the "highlight" one where you could allow multiple views to
> > be selected for highlighting.
>
> That's hard to do in a menu, but I could do it in a separate pane.
> Or, I could draw a series of tabs between the menu bar and the
> graph/headline/author/date panes. Each tab would have the view name,
> a radiobutton to select it for highlighting, and a close button.
Actually, having used this thing (and thought about) some more, I'm afraid
that I'll have to just admit that my whole "highlight" thing was
misdesigned.
One is just an interface issue, and I think that it would be fixed by just
removing the highlight entry from the "view" menu, and making it a menu of
its own. That, I think, would fix the user interface to be more obvious
and intuitive.
But the real thing I found is that when I decided I wanted to highlight, I
didn't actually want to highlight by "git-rev-list" at all. At least not
most of the time.
So far, what I've wanted to highlight by is:
- "does it touch this file/directory/pathspec"
This is _close_ to "git-rev-list", and you can (and do) actually
implement it as that, but it's stupid to do it that way. You just spend
extra time. It's literally much better to do
cat commit-list | git-diff-tree -s --stdin -- <pathspec>
which is a hell of a lot more efficient, since you already have the
commit-list you're interested in (and, in fact, this allows you to do
things efficiently only for the current _visible_ commits, if you want
to, which might be an important optimization for large views).
- "Does the author/committer match xyz*"
I ended up using the "search" button for this, and it worked, but the
highlight feature would just have done it much better. Especially if
there was a way to do "go to next highlight", instead of just "go to
next commit"
Again, this is actually most easily done by just using the commit-list
you already _have_. Not with adding a new argument to "git-rev-list"
and trying to filter two views. Also, again, this can actually be done
for just the "visible" ones, not the whole view.
- "highlight the commits [not] reachable from the selected commit"
Now, this literally is "git-rev-list", but it's a variation on it: you
don't want a new view, you really want the _old_ view (exact same
git-rev-list arguments), but you add "^commit" to the list of
revisions. And then you (conditionally) invert the highlighting if you
wanted "reachable" rather than "not reachable".
And the current "create a new view, and overlay that on the old one"
approach really isn't that good. My mistake, it was me who suggested it.
What do you think?
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Theodore Tso @ 2006-05-03 16:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi,
Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030817580.4086@g5.osdl.org>
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
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-03 16:46 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30605030919xf54e1c2j1e27c4ce04b6864d@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 5/3/06, Jakub Narebski <jnareb@gmail.com> 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/
>
> 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
^ permalink raw reply
* RE: problem with plain git clone
From: Haruki Dai-r35557 @ 2006-05-03 16:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
Hi Kumar,
Could you enable post update hook? I couldn't clone through http:.
Thanks,
Dai
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Kumar Gala
> Sent: Wednesday, May 03, 2006 10:46 AM
> To: Shawn Pearce
> Cc: git@vger.kernel.org
> Subject: Re: problem with plain git clone
>
>
> On May 3, 2006, at 9:31 AM, Shawn Pearce wrote:
>
> > Kumar Gala <galak@kernel.crashing.org> wrote:
> >> Anyone see an issues like the following:
> >>
> >> [kgala@kgala_lnx z]$ git clone
> git://git.kernel.org:/pub/scm/boot/u-
> >> boot/galak/u-boot.git
> >> git clone
> git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
> >> fatal: unable to connect a socket (Connection timed out)
> >
> > There's no GIT daemon running on the empty port. Notice the ':'
> > appearing right after '.org'.
> >
> > Hmm, that sounds like a bug in the protocol URL parser...
>
> Yeah, that was it. thanks.
>
> - kumar
> -
> 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
>
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 16:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3al00$1dj$1@sea.gmane.org>
On 5/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Linus Torvalds wrote:
> > On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> >>
> >> 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
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-03 16:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605030856540.4086@g5.osdl.org>
Linus Torvalds wrote:
>
>
> On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
>>
>> 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
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 16:06 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <4d8e3fd30605030839i2bb5de8dka8a4af27755051cf@mail.gmail.com>
On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
>
> 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
^ permalink raw reply
* Re: problem with plain git clone
From: Kumar Gala @ 2006-05-03 15:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060503143130.GA9172@spearce.org>
On May 3, 2006, at 9:31 AM, Shawn Pearce wrote:
> Kumar Gala <galak@kernel.crashing.org> wrote:
>> Anyone see an issues like the following:
>>
>> [kgala@kgala_lnx z]$ git clone git://git.kernel.org:/pub/scm/boot/u-
>> boot/galak/u-boot.git
>> git clone git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
>> fatal: unable to connect a socket (Connection timed out)
>
> There's no GIT daemon running on the empty port. Notice the ':'
> appearing right after '.org'.
>
> Hmm, that sounds like a bug in the protocol URL parser...
Yeah, that was it. thanks.
- kumar
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 15:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030817580.4086@g5.osdl.org>
On 5/3/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 3 May 2006, Andreas Ericsson wrote:
> >
> > 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
^ permalink raw reply
* [PATCH] Add a simple makefile
From: Pavel Roskin @ 2006-05-03 15:34 UTC (permalink / raw)
To: Catalin Marinas, git
From: Pavel Roskin <proski@gnu.org>
---
Makefile | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..df77d97
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,23 @@
+PREFIX = $(HOME)
+DESTDIR = /
+PYTHON = python
+
+all:
+ $(PYTHON) setup.py build
+
+install:
+ $(PYTHON) setup.py install --prefix=$(PREFIX) --root=$(DESTDIR)
+
+doc:
+ cd doc && $(MAKE) all
+
+test:
+ cd t && $(MAKE) all
+
+clean:
+ for dir in doc t; do \
+ (cd $$dir && $(MAKE) clean); \
+ done
+ rm -rf build
+ rm -f stgit/*.pyc
+ rm -f stgit/commands/*.pyc
^ permalink raw reply related
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-03 15:30 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30605030824v40017178o366a9d8aa83557e8@mail.gmail.com>
Paolo Ciarrocchi wrote:
> Would be fantastic to see a fair comparison of the two tools but I
> can't find anything useful on the web.
Three tools: Git/Cogito, Mercurial and Monotone.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 15:30 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <4458C5D7.8010501@op5.se>
On Wed, 3 May 2006, Andreas Ericsson wrote:
>
> 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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox