* Re: gitweb - feature request
From: Kay Sievers @ 2005-08-12 20:33 UTC (permalink / raw)
To: Mitchell Blank Jr; +Cc: Ian Campbell, git
In-Reply-To: <20050810083113.GN49964@gaz.sfgoth.com>
On Wed, Aug 10, 2005 at 01:31:13AM -0700, Mitchell Blank Jr wrote:
> Ian Campbell wrote:
> > I used to subscribe to the kernel RSS feed (using blam) but I found I
> > was only getting the most recent 20 commits, which wasn't much good when
> > a big batch went in because I would miss some.
>
> Yes, I have that problem too. It appears to be just the way that gitweb
> works - look at the "git_rss" function in the source:
> ftp://ftp.kernel.org/pub/software/scm/gitweb/gitweb.cgi
>
> Kay -- is there any chance of fixing this? I love reading the kernel
> commits via RSS but this makes it a lot less usable than it could be.
> Really it should return all commits within, say, the last 36 hours so as
> long as your aggregator polls reasonably often you won't miss anyhing.
It's 30 now and up to 150 if they are not older than 48 hours.
We can change the numbers, if you hava a better idea...
> The other thing on my wishlish is diffstat -- sometimes the commit messages
> can be a little ambiguous and just adding what files were changed would
> help alot. For commits that touch a large number of files maybe it could
> just show the files that changed the most like:
For now it just lists all changed files to the log message, similar to the
"commit" view. Is that ok, or do we really need the diffstat, It may be
a bit expensive to generate it for all the commits with every RSS request...
Thanks,
Kay
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Junio C Hamano @ 2005-08-12 20:36 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050812190739.AC222352633@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> Has anybody any information if SourceForge is going to provide git /
> cogito / ... for the projects they host? I asked SF, and they openend
> a new Feature Request (item #1252867); the message I received sounded
> as if I was the first person on the planet to ask...
>
> Am I really alone with this?
Earlier Johannes Schindelin sent in a bug report he found on one
architecture in their build farm, so apparently he has access to
it.
I'd actually welcome people who have access to such a build
network, time and of course willingness to start portability
fixes on various platforms for git-core.
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Daniel Barkalow @ 2005-08-12 20:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050812190739.AC222352633@atlas.denx.de>
On Fri, 12 Aug 2005, Wolfgang Denk wrote:
> This is somewhat off topic here, so I apologize, but I didn't know
> any better place to ask:
>
> Has anybody any information if SourceForge is going to provide git /
> cogito / ... for the projects they host? I asked SF, and they openend
> a new Feature Request (item #1252867); the message I received sounded
> as if I was the first person on the planet to ask...
>
> Am I really alone with this?
The git architecture makes the central server less important, and it's
easy to run your own. Also, kernel.org is providing space to a set of
people with a large overlap with git users, since git hasn't been
particularly publicized and kernel.org is hosting git.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Kirby C. Bohling @ 2005-08-12 21:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Wolfgang Denk, git
In-Reply-To: <Pine.LNX.4.63.0508121634570.12816@iabervon.org>
On Fri, Aug 12, 2005 at 04:46:34PM -0400, Daniel Barkalow wrote:
> On Fri, 12 Aug 2005, Wolfgang Denk wrote:
>
> > This is somewhat off topic here, so I apologize, but I didn't know
> > any better place to ask:
> >
> > Has anybody any information if SourceForge is going to provide git /
> > cogito / ... for the projects they host? I asked SF, and they openend
> > a new Feature Request (item #1252867); the message I received sounded
> > as if I was the first person on the planet to ask...
> >
> > Am I really alone with this?
>
> The git architecture makes the central server less important, and it's
> easy to run your own. Also, kernel.org is providing space to a set of
> people with a large overlap with git users, since git hasn't been
> particularly publicized and kernel.org is hosting git.
>
I don't think he wants sourceforge to host git, I think he'd like
sourceforge to provide access to source trees via git, instead of
cvs. Read that as, I want to do:
git pull http://www.sourceforge.net/packageName
instead of:
cvs -d pserver:www.sourceforge.net co packageName
While it might be easy to host your own project, Linus has some
infamous quote I'll paraphrase as "Real men don't make backups, they
upload to public FTP and let other's make backups...".
I know if I was working on OSS project, I wouldn't be too
heartbroken to let someone else run the security, backup, and
general SA duties for me. More time to write code that way...
Kirby
^ permalink raw reply
* Re: gitweb - feature request
From: Mitchell Blank Jr @ 2005-08-12 21:16 UTC (permalink / raw)
To: Kay Sievers; +Cc: Ian Campbell, git
In-Reply-To: <20050812203322.GB9696@vrfy.org>
Kay Sievers wrote:
> It's 30 now and up to 150 if they are not older than 48 hours.
> We can change the numbers, if you hava a better idea...
Is it really hard to just make it purely time-based (git-rev-list --max-age)?
Think of if Linus is merging with a lot of people and then pushes the results
to the master repository -- suddenly there's, say, 400 new commits since the
last time my aggregator checked 2 hours ago.
> For now it just lists all changed files to the log message, similar to the
> "commit" view. Is that ok, or do we really need the diffstat,
It looks great, thanks! diffstat would be slightly nicer but not a big
deal.
> It may be
> a bit expensive to generate it for all the commits with every RSS request...
Well if the RSS feed's popularity takes off you'll probably want to *not*
generate it every time and instead serve it from a static file. This can
be as simple as a Makefile like:
commits.rss: $(GITDIR)/refs/heads/master
/path/to/myperlscript.pl $(GITDIR) > commits.rss.NEW && chmod 444 commits.rss.NEW && mv commits.rss.NEW commits.rss
and then call "make -C /my/rss/dir -s -f /path/to/mymakefile.mk" from cron
every minute.
Serving the rss from a static file has the big advantage that a well-behaved
aggregator will only request it if the modification date changed which saves
everyone bandwidth.
-Mitch
^ permalink raw reply
* [PATCH] Fix documentation installation
From: Petr Baudis @ 2005-08-12 21:11 UTC (permalink / raw)
To: git
Documentation's install target now depends on man since
it installs manpages. It now also installs the .txt files, to
$prefix/share/doc/cogito/txt/ by default. A separate install-html target
was added for installing .html files to $prefix/share/doc/cogito/html/. It
isn't part of the install target since building HTML might cause problems
on some asciidoc installations (like, well, mine) as xhtml11 appears
not to be an official asciidoc plugin, or so asciidoc claims.
The missing dependency was pointed out by Jonas Fonseca.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
commit e7b483b293fb7d359dcebf974e6784f8b14f2ab1
tree 5e998614a0dbce85758de5be847306837953bb42
parent 2b0289c3805d0c99eb031a7116948a3cb4ddf332
author Petr Baudis <pasky@suse.cz> Fri, 12 Aug 2005 22:58:13 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 12 Aug 2005 22:58:13 +0200
Documentation/Makefile | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -11,6 +11,9 @@ bin=$(prefix)/bin
mandir=$(prefix)/man
man1=$(mandir)/man1
man7=$(mandir)/man7
+docdir=$(prefix)/share/doc/git-core
+txtdir=$(docdir)/txt
+htmldir=$(docdir)/html
# DESTDIR=
INSTALL=install
@@ -33,11 +36,18 @@ man: man1 man7
man1: $(DOC_MAN1)
man7: $(DOC_MAN7)
-install:
+install: man
+ $(INSTALL) -m755 -d $(DESTDIR)/$(txtdir)
+ $(INSTALL) $(MAN1_TXT) $(MAN7_TXT) $(DESTDIR)/$(txtdir)
$(INSTALL) -m755 -d $(DESTDIR)/$(man1) $(DESTDIR)/$(man7)
$(INSTALL) $(DOC_MAN1) $(DESTDIR)/$(man1)
$(INSTALL) $(DOC_MAN7) $(DESTDIR)/$(man7)
+install-html: html
+ $(INSTALL) -m755 -d $(DESTDIR)/$(htmldir)
+ $(INSTALL) $(DOC_HTML) $(DESTDIR)/$(htmldir)
+
+
# 'include' dependencies
git-diff-%.txt: diff-format.txt diff-options.txt
touch $@
diff --git a/tools/Makefile b/tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -18,7 +18,7 @@ git-%: %.c
all: $(PROGRAMS)
install: $(PROGRAMS) $(SCRIPTS)
- $(INSTALL) -m755 -d $(dest)$(bindir)
+ $(INSTALL) -m755 -d $(DESTDIR)$(bindir)
$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(DESTDIR)$(bindir)
clean:
^ permalink raw reply
* Re: [PATCH] Fix documentation installation
From: Petr Baudis @ 2005-08-12 21:14 UTC (permalink / raw)
To: git
In-Reply-To: <20050812211145.GA20812@pasky.ji.cz>
Dear diary, on Fri, Aug 12, 2005 at 11:11:45PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> told me that...
> diff --git a/tools/Makefile b/tools/Makefile
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -18,7 +18,7 @@ git-%: %.c
> all: $(PROGRAMS)
>
> install: $(PROGRAMS) $(SCRIPTS)
> - $(INSTALL) -m755 -d $(dest)$(bindir)
> + $(INSTALL) -m755 -d $(DESTDIR)$(bindir)
> $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(DESTDIR)$(bindir)
>
> clean:
I should read patches after myself, especially when messing with them.
This hunk is obviously superflous, so feel free to drop it from that
patch if you are in a "patch purity" mood. OTOH it is obviously valid
fix. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Marco Costalba @ 2005-08-12 21:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
Wolfgang Denk wrote:
>This is somewhat off topic here, so I apologize, but I didn't know
>any better place to ask:
>
>Has anybody any information if SourceForge is going to provide git /
>cogito / ... for the projects they host? I asked SF, and they openend
>a new Feature Request (item #1252867); the message I received sounded
>as if I was the first person on the planet to ask...
>
>Am I really alone with this?
>
I have asked few days ago the same thing, suggesting my qgit project, that is
already hosted on SF, as testing candidate. No final answer yet,
just notification my request will be processed.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] Use "-script" postfix for scripts
From: Linus Torvalds @ 2005-08-12 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwtmrxjbb.fsf@assigned-by-dhcp.cox.net>
On Fri, 12 Aug 2005, Junio C Hamano wrote:
>
> I have never liked the original -script name convention. It
> only meant that they are implemented as scripts (as opposed to
> those on the $(PROG) Makefile variable), but the end users who
> end up typing their names from the command line, and to a lesser
> degree the people who use them in their scripts, should not care
> how they are implemented to begin with.
Well, end users _don't_ care, since they are supposed to use just a simple
"git xxx".
The advantage with "git-xxx-script" is for git developers: at least yours
truly does "grep xyz *.c" all the time, and the "grep abc *-script" is
entirely analogous to that. That's where the "-script" ending comes from:
it really helps pick out the stuff you can grep from (as opposed to the
stuff that got compiled and isn't greppable).
Sure, I could have called it ".sh" instead to make it look even more like
a shell script thing, but I actually think "-script" describes any
scripting language - shell, perl, you name it..
Linus
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Wolfgang Denk @ 2005-08-12 22:01 UTC (permalink / raw)
To: Kirby C. Bohling; +Cc: Daniel Barkalow, git
In-Reply-To: <20050812210611.GF13550@birddog.com>
In message <20050812210611.GF13550@birddog.com> you wrote:
>
> > The git architecture makes the central server less important, and it's
> > easy to run your own. Also, kernel.org is providing space to a set of
Yes, cou can - but for a popular project like U-Boot in our case you
don't really want to ;-)
> > people with a large overlap with git users, since git hasn't been
> > particularly publicized and kernel.org is hosting git.
>
> I don't think he wants sourceforge to host git, I think he'd like
> sourceforge to provide access to source trees via git, instead of
> cvs. Read that as, I want to do:
Correct, that's what I am looking for. My hope is that if enough
people ask SF might actually provide such a service.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Disc space - the final frontier!
^ permalink raw reply
* Re: [PATCH] Use "-script" postfix for scripts
From: Ryan Anderson @ 2005-08-12 22:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.58.0508121451590.3295@g5.osdl.org>
On Fri, Aug 12, 2005 at 02:55:01PM -0700, Linus Torvalds wrote:
>
> Sure, I could have called it ".sh" instead to make it look even more like
> a shell script thing, but I actually think "-script" describes any
> scripting language - shell, perl, you name it..
See, for example, the history on git-rename-script for why this is good.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Linus Torvalds @ 2005-08-12 22:27 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Wolfgang Denk, git
In-Reply-To: <Pine.LNX.4.63.0508121634570.12816@iabervon.org>
On Fri, 12 Aug 2005, Daniel Barkalow wrote:
>
> The git architecture makes the central server less important, and it's
> easy to run your own.
On the other hand:
- the git architecture is admirably suited to an _untrusted_ central
server, ie exactly the SourceForge kind of setup. I realize that the
people at SourceForge probably think they are trustworthy, but in the
big picture, even SF probably would prefer people to see them as a
_distribution_ point, not the final authority.
IOW, with git (unlike, for example CVS), you can have a useful
distribution point that is _not_ one that the developers have to
control or even necessarily want to control. Which is exactly the
kind of setup that would match what SF does.
So with git, developers don't have to trust SF, and if SF is down or
something bad happens (disk crash, bad backups, whatever), you didn't
"lose" anything - the real development wasn't being done at SF anyway,
it was a way to _connect_ the people who do real development.
- Every developer wants to have their own history and complete source
control, but very few developers actually have good distribution
resources. "kernel.org" works for a few projects, and might be fine to
expand a bit past what it does now, but kernel.org doesn't eevn try to
do (nor _want_ to do, I bet) the kinds of things that SF does.
Yes, developers can just merge with each other directly, and git allows
that, but it's actually not very convenient - not because of git
itself, but because of just doing the maintenance. For example, I don't
allow incoming traffic to my machines, and I feel _much_ better that
way. No MIS, no maintenance, and much fewer security issues.
This is _exactly_ where something like SF really ends up being helpful.
It's a _hosting_ service, and git is eminently suitable to being
hosted, exactly because of its distributed approach. It needs very few
hosting services: you could make do with a very very limited shell
access, and in fact I tried to design the "git push" protocol so that
you could give people ssh "shell" access, where the "shell" was not a
real shell at all, but something that literally just implemented four
or five commands ("git-receive-pack" and some admin commands to do
things like creation/removal of whole archives etc).
> Also, kernel.org is providing space to a set of people with a large
> overlap with git users, since git hasn't been particularly publicized
> and kernel.org is hosting git.
kernel.org certainly works well enough for the few projects that use it,
but I don't think it's going to expand all that much.
And it's possible that git usage won't expand all that much either. But
quite frankly, I think git is a lot better than CVS (or even SVN) by now,
and I wouldn't be surprised if it started getting some use outside of the
git-only and kernel projects once people start getting more used to it.
And so I'd be thrilled to have some site like SF support it.
bkbits.net used to do that for BK projects, and there were a _lot_ of
projects that used it.
Linus
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Martin Langhoff @ 2005-08-12 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Urlichs, git
In-Reply-To: <7vpssiucss.fsf@assigned-by-dhcp.cox.net>
> I just noticed from "dpkg --info" output that the generated
> git-tk has "Architecture: i386". Shouldn't it read "all" and
> resulting package also named git-tk_${VERSION}_all.deb, instead
> of whatever architecture I happened to build it?
It is correct to have Architecture: i386, as you'd naturally have
multiple binary packages. When this is uploaded to the Debian archive,
all the other architectures are built in the "buildd" farm. That's why
the source package 'native' arch is 'any'.
Packages with arch 'all' are interpreted languages. The cogito package
will probably be for 'all' arches, and just be one binary package.
cheers,
martin
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Martin Langhoff @ 2005-08-12 23:01 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Kirby C. Bohling, Daniel Barkalow, git
In-Reply-To: <20050812220120.EF075353AED@atlas.denx.de>
> > I don't think he wants sourceforge to host git, I think he'd like
> > sourceforge to provide access to source trees via git, instead of
> > cvs. Read that as, I want to do:
>
> Correct, that's what I am looking for. My hope is that if enough
> people ask SF might actually provide such a service.
Ubuntu's 'launchpad' project is trying to do that (a SCM 'proxy' of
sorts) with Arch/Bazaar/BazaarNG/Whatever. It takes massive ammounts
of diskpace and computing power to be tracking external cvs/svn repos
in your SCM format of choice. The talked abundantly about this at the
last Debconf in nightless helsinki.
I know I will be running GIT public repos that mirror CVS repos of a
few large-ish projects I work on a lot, and are starting to strain
CVS's ability to coordinate work. I am keen on starting a Wiki on
'git/cogito' techniques and usage strategies, and my first entry is
going to be about how to track an external project this way.
cheers,
martin
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Daniel Barkalow @ 2005-08-12 23:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Wolfgang Denk, git
In-Reply-To: <Pine.LNX.4.58.0508121513530.3295@g5.osdl.org>
On Fri, 12 Aug 2005, Linus Torvalds wrote:
> And it's possible that git usage won't expand all that much either. But
> quite frankly, I think git is a lot better than CVS (or even SVN) by now,
> and I wouldn't be surprised if it started getting some use outside of the
> git-only and kernel projects once people start getting more used to it.
> And so I'd be thrilled to have some site like SF support it.
I certainly think it's going to happen; it's just not surprising that it
hasn't happened yet. Once there's a stable release and some publicity, I'd
expect SF to see it as worthwhile. But a hosting site with git-only shell
access needs to know what the necessary programs are going to be, which we
haven't committed to quite yet.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Martin Langhoff @ 2005-08-12 23:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Wolfgang Denk, git
In-Reply-To: <Pine.LNX.4.58.0508121513530.3295@g5.osdl.org>
> - the git architecture is admirably suited to an _untrusted_ central
> server, ie exactly the SourceForge kind of setup. I realize that the
Definitely. And beyond that too. Using SF for CVS means that when SF's
CVS service is down (often enough) you can't commit (or even fscking
diff) until they are back up. Every single damn operation does a
roundtrip. This also means a huge load on their servers.
I'm sure SF will be glad to see CVS fall our of favour.
> Yes, developers can just merge with each other directly
I take it that you mean an exchange of patches that does not depend on
having public repos. What are the mechanisms available on that front,
other than patchbombs?
> This is _exactly_ where something like SF really ends up being helpful.
> It's a _hosting_ service, and git is eminently suitable to being
Not sure whether SF is offering rsync, but they do support hosting of
arbitrarty data -- and a project using GIT can use that to host
several developer trees . It'd be nice if SF offered gitweb and
similar niceties. As my usage of GIT increases, I may add support for
it on Eduforge.org
If I had more (hw/time) resources I'd do the git proxying of CVS
projects, but that's huge.
> And so I'd be thrilled to have some site like SF support it.
Eduforge's charter is to host education-related projects, so that's
not a free-for-all-comers, but I'm considering git support, as our
usage of git is growing.
cheers,
martin
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: David Lang @ 2005-08-12 23:24 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Wolfgang Denk, Kirby C. Bohling, Daniel Barkalow, git
In-Reply-To: <46a038f905081216013941b2c@mail.gmail.com>
On Sat, 13 Aug 2005, Martin Langhoff wrote:
>>> I don't think he wants sourceforge to host git, I think he'd like
>>> sourceforge to provide access to source trees via git, instead of
>>> cvs. Read that as, I want to do:
>>
>> Correct, that's what I am looking for. My hope is that if enough
>> people ask SF might actually provide such a service.
>
> Ubuntu's 'launchpad' project is trying to do that (a SCM 'proxy' of
> sorts) with Arch/Bazaar/BazaarNG/Whatever. It takes massive ammounts
> of diskpace and computing power to be tracking external cvs/svn repos
> in your SCM format of choice. The talked abundantly about this at the
> last Debconf in nightless helsinki.
Actually, if HPA can (or has) work out the kinks for combining the object
stores for different projects I think you will find that a site like
sourceforge could actually find that across all their differnt projects
git will require significantly less space then first thought. I believe
that there is a significant number of files that are going to be the same
in different project (for example COPYING, or if a project is forked, most
of the files in a project) and therfor will just refer to the same object
blob.
now when you start makeing packs this sort of thing can make the optimal
logic for deciding what's in each pack 'interesting', but as long as each
pack is self contained the rest of the git tools will handle things just
fine.
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
* Re: [OT?] git tools at SourceForge ?
From: Linus Torvalds @ 2005-08-12 23:46 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Daniel Barkalow, Wolfgang Denk, git
In-Reply-To: <46a038f90508121617560d00c@mail.gmail.com>
On Sat, 13 Aug 2005, Martin Langhoff wrote:
>
> > Yes, developers can just merge with each other directly
>
> I take it that you mean an exchange of patches that does not depend on
> having public repos. What are the mechanisms available on that front,
> other than patchbombs?
Just have a shared trusted machine.
A lot of "core" developers end up having machines that they may not
control, and that they may not be able to use as major distribution
points, but that they _can_ share with others.
For example, "master.kernel.org" ends up being that for the kernel: you
don't have to have an account on master, but most of the core developers
do, so they can use it as a short-cut that is independent of the actual
"public" site.
Similarly, some people are perfectly willing to give other trusted
developers a ssh login on their machine - and that's a perfectly fine way
to sync repositories directly if you have even a slow DSL link. You'd
never want to _distribute_ the result over DSL, though.
The point being that you can certainly sync up to others without going
through a public site.
[ We _could_ also just send pack-files as email attachments. There's
nothing fundamentally wrong with doing the object discovery that
"git-send-pack" does on its own manually over email.
In other words: you could easily do something like "Hey, I've got your
commit as of yesterday, ID <sha1>, can you send me your current
top-of-tree SHA1 name and the pack-file between the two?" and have
direct git-to-git synchronization even over email.
NOTE NOTE NOTE! BK did this, with a "bk send" and "bk receive". I hated
it, which is why I'd never do scripts like that. But I think it's a
valid thing to do when you're cursing the fact that the central
repository is down, and has been down for five hours, and you don't know
how long it will take to get back up, and you don't have _any_ other
choices ]
> > This is _exactly_ where something like SF really ends up being helpful.
> > It's a _hosting_ service, and git is eminently suitable to being
>
> Not sure whether SF is offering rsync, but they do support hosting of
> arbitrarty data -- and a project using GIT can use that to host
> several developer trees.
The problem with the arbitrary data approach (and rsync) is that the git
repositories can get out of sync.
We haven't seen it very often on kernel.org, but we _do_ see it. I think
I've got something like three bug reports from people saying "your tree is
corrupted" because it so happened that the mirroring was on-going at the
same time I did a push, and the mirroring caught an updated HEAD without
actually having caught all of the objects that HEAD referenced.
Now, all the git tools do write things in the right order, and mirror
scripts etc _tend_ to mirror in alphabetical order (and "objects" come
before "refs" ;), so you really have to hit the right window where a git
tool updates the git repository at the same time as a mirroring sweep is
going on, but it definitely _does_ happen.
It just happens seldom enough that most people haven't noticed. But if
you've seen the gitweb page go blank for one of the projects, you now know
why it can happen..
And this is inevitable when you have a non-git-aware server. You really
need to update the objects in the right order, and to get the right order
you do have to be git-aware.
> It'd be nice if SF offered gitweb and
> similar niceties. As my usage of GIT increases, I may add support for
> it on Eduforge.org
I think we'll find that it's a learning process, to just find out what
drives site managers mad (we certainly found the problem with lots of
small files on kernel.org out ;). Having a few sites that do it and tell
the others what gotchas there are involved with it (and what scripts they
use for maintaining stuff like auto-packing etc) is all a learning
experience.
Linus
^ permalink raw reply
* [PATCH] more Debian packaging fixes
From: Matthias Urlichs @ 2005-08-13 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpssiucss.fsf@assigned-by-dhcp.cox.net>
git-tk should be architecture independent.
git-core forgot to depend on perl.
Signed-Off-By: Matthias Urlichs <smurf@debian.org>
---
Hi,
Junio C Hamano:
> Matthias Urlichs <smurf@smurf.noris.de> writes:
>
> > - Split gitk off to its own package;
> > it needs tk installed, but nothing else does.
>
> I just noticed from "dpkg --info" output that the generated
> git-tk has "Architecture: i386". Shouldn't it read "all" and
> resulting package also named git-tk_${VERSION}_all.deb, instead
> of whatever architecture I happened to build it?
>
True.
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
git-core (0.99.5-0) unstable; urgency=low
* Split off gitk.
+ - ... into an architecture-independent package.
-- Matthias Urlichs <smurf@debian.org> Thu, 11 Aug 2005 01:43:24 +0200
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, patch, diff, rcs
+Depends: ${perl:Depends}, ${shlibs:Depends}, ${misc:Depends}, patch, diff, rcs
Recommends: rsync, curl, ssh, libmail-sendmail-perl, libemail-valid-perl
Conflicts: git
Description: The git content addressable filesystem
@@ -18,7 +18,7 @@ Description: The git content addressable
similar to other SCM tools.
Package: git-tk
-Architecture: any
+Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, tk8.4
Description: The git content addressable filesystem, GUI add-on
This package contains 'gitk', the git revision tree visualizer
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -65,33 +65,36 @@ install: build
dh_movefiles -p git-core
find debian/tmp -type d -o -print | sed -e 's/^/? /'
-binary: build install
+binary-arch: build install
dh_testdir
dh_testroot
- dh_installchangelogs
- dh_installdocs
- dh_installexamples
-# dh_installmenu
-# dh_installdebconf
-# dh_installlogrotate
-# dh_installemacsen
-# dh_installpam
-# dh_installmime
-# dh_installinit
-# dh_installcron
-# dh_installinfo
- dh_installman
- dh_link
- dh_strip
- dh_compress
- dh_fixperms
-# dh_perl
-# dh_python
- dh_makeshlibs
- dh_installdeb
- dh_shlibdeps
- dh_gencontrol
- dh_md5sums
- dh_builddeb
+ dh_installchangelogs -a
+ dh_installdocs -a
+ dh_strip -a
+ dh_compress -a
+ dh_fixperms -a
+ dh_perl -a
+ dh_makeshlibs -a
+ dh_installdeb -a
+ dh_shlibdeps -a
+ dh_gencontrol -a
+ dh_md5sums -a
+ dh_builddeb -a
+
+binary-indep: build install
+ dh_testdir
+ dh_testroot
+ dh_installchangelogs -i
+ dh_installdocs -i
+ dh_compress -i
+ dh_fixperms -i
+ dh_makeshlibs -i
+ dh_installdeb -i
+ dh_shlibdeps -i
+ dh_gencontrol -i
+ dh_md5sums -i
+ dh_builddeb -i
+
+binary: binary-arch binary-indep
.PHONY: build clean binary install clean debian-clean
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
GUBBISH [a portmanteau of "garbage" and "rubbish"?] n. Garbage; crap;
nonsense. "What is all this gubbish?"
-- From the AI Hackers' Dictionary
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Matthias Urlichs @ 2005-08-13 0:41 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f905081215547618441c@mail.gmail.com>
Hi,
Martin Langhoff:
> It is correct to have Architecture: i386, as you'd naturally have
> multiple binary packages.
However, git(-t)k doesn't contain any i386 code, just a tk script.
> Packages with arch 'all' are interpreted languages.
Exactly. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
compuberty, n:
The uncomfortable period of emotional and hormonal changes a
computer experiences when the operating system is upgraded and
a sun4 is put online sharing files.
^ permalink raw reply
* Re: [OT?] git tools at SourceForge ?
From: Daniel Barkalow @ 2005-08-13 1:16 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Wolfgang Denk, git
In-Reply-To: <46a038f90508121617560d00c@mail.gmail.com>
On Sat, 13 Aug 2005, Martin Langhoff wrote:
> > Yes, developers can just merge with each other directly
>
> I take it that you mean an exchange of patches that does not depend on
> having public repos. What are the mechanisms available on that front,
> other than patchbombs?
If each developer has a trivial web server, they can put their output
there, and everyone else can pull from it, because it only needs to serve
static files out of a directory structure that the programs create
regularly. Of course, this is only strictly different from a public repo
in that you don't advertize it beyond the other developers. But it's a
within-system equivalent to posting a link to a web-hosted patch set,
which people sometimes do to pass things around.
> > And so I'd be thrilled to have some site like SF support it.
>
> Eduforge's charter is to host education-related projects, so that's
> not a free-for-all-comers, but I'm considering git support, as our
> usage of git is growing.
If you contribe the git support to gforge, presumably similar hosting
sites will pick it up before too long.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Cloning speed comparison
From: Petr Baudis @ 2005-08-13 1:54 UTC (permalink / raw)
To: git
Hello,
I've wondered how slow the protocols other than rsync are, and the
(well, a bit dubious; especially wrt. caching on the remote side)
results are:
git clone-pack:ssh 25s
git rsync 27s
git http-pull 47s
git dumb-http 54s
git ssh-pull 660s
cogito clone-pack:ssh 35s (!)
cogito rsync 140s
cogito ssh-pull 480s
cogito http-pull extrapolated to about an hour!
cogito dumb-http N/A (missing info in the repository)
(I didn't test the git server protocol, since kernel.org doesn't run
git server and I was too lazy to setup one.)
The git repository contains one big pack, one small pack and few
standalone objects (5882 objects in total), while cogito is standalone
objects only (9670 objects in total, 8681 reachable).
The numbers are off by some epsilons, as I didn't bother with multiple
measures, but shouldn't be hugely off for a general comparison. The
network connection has 2048kbit/s download, the other side was
www.kernel.org for HTTP and rsync, and master.kernel.org for ssh.
Pulling from localhost (128M of RAM, 5M to 30M free - awful, yes):
cogito rsync:ssh 150s
cogito ssh-pull 120s (but didn't complete, see PS)
cogito http-pull 260s
cogito clone-pack:ssh 340s
Anyway, clone-pack is a clear winner for networks (but someone should
re-check that, especially compared to rsync, wrt. server-side file
caching); really cool fast, but not very practical for anonymous access.
Any volunteers for a simple CGI (or gitweb addon) script + HTTP support
in clone-pack? HTTP is certainly the most suitable protocol for
anonymous pulls, so it's a shame it's still that sluggish.
It is so slow here since it has some very ugly access pattern on the
objects database and my RAM is full so it does not get cached; even on
the servers, it was slower at first - unfortunately, I didn't measure
that, so what's in the top table are second accesses. Still, I would
expect the big repositories to stay mostly in the server cache, so this
isn't that big problem for those, I think.
PS:
With the latest git version as of time of writing this:
$ time cg-clone git+ssh://pasky@localhost/home/pasky/WWW/dev/git/.g cogito
...
progress: 5759 objects, 10292457 bytes
$ time cg-clone http://localhost/~pasky/dev/git/.g cogito
...
progress: 8681 objects, 14881571 bytes
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: Cloning speed comparison
From: Linus Torvalds @ 2005-08-13 2:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813015402.GC20812@pasky.ji.cz>
On Sat, 13 Aug 2005, Petr Baudis wrote:
>
> Anyway, clone-pack is a clear winner for networks (but someone should
> re-check that, especially compared to rsync, wrt. server-side file
> caching); really cool fast, but not very practical for anonymous access.
git-daemon is for the anonymous access case, either started from inetd
(or any other external "listen to port, exec service" thing), or with the
built-in listening stuff.
It uses exactly the same protocol and logic as the regular ssh clone-pack
thing, except it doesn't authenticate the remote end: it only checks that
the local end is accepting anonymous pulls by checking whether there is a
"git-daemon-export-ok" file in the git directory.
In my tests, the git daemon was noticeably faster than ssh, if only
because the authentication actually tends to be a big part of the overhead
in small pulls.
[ Hey. There's a deer outside my window eating our roses again. Cute ]
Linus
^ permalink raw reply
* Re: Cloning speed comparison
From: Petr Baudis @ 2005-08-13 3:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, ftpadmin
In-Reply-To: <Pine.LNX.4.58.0508121908180.3295@g5.osdl.org>
Dear diary, on Sat, Aug 13, 2005 at 04:12:26AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Sat, 13 Aug 2005, Petr Baudis wrote:
> >
> > Anyway, clone-pack is a clear winner for networks (but someone should
> > re-check that, especially compared to rsync, wrt. server-side file
> > caching); really cool fast, but not very practical for anonymous access.
>
> git-daemon is for the anonymous access case, either started from inetd
> (or any other external "listen to port, exec service" thing), or with the
> built-in listening stuff.
>
> It uses exactly the same protocol and logic as the regular ssh clone-pack
> thing, except it doesn't authenticate the remote end: it only checks that
> the local end is accepting anonymous pulls by checking whether there is a
> "git-daemon-export-ok" file in the git directory.
>
> In my tests, the git daemon was noticeably faster than ssh, if only
> because the authentication actually tends to be a big part of the overhead
> in small pulls.
Oh. Sounds nice, are there plans to run this on kernel.org too? (So far,
90% of my GIT network activity happens with kernel.org; the rest is with
my notebook, and I want to keep that ssh.)
BTW, is the pack protocol flexible enough to be extended to support
pushing? That would be great as well. You might suggest just using ssh,
but that (i) requires you to be root on the machine to add new users
(ii) consequently adds administrative burden (iii) isn't easy to set up
so that the user has no shell access, shall you want to restrict that.
> [ Hey. There's a deer outside my window eating our roses again. Cute ]
Oh, it must be nice in Oregon. I can't imagine anything like that to
happen in Czechia unless you live at a solitude or in some lonely tiny
village.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] fetch-pack: start multi-head pulling.
From: Matthias Urlichs @ 2005-08-13 3:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vk6irumv3.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> I have been trying, admittably perhaps not very successfully, to
> stay away from bashism in the core GIT scripts.
We should probably use #!/bin/bash for scripts with bashisms...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
He has more goodness in his little finger Than you have in your whole
body.
-- Jonathan Swift
^ 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