Re: [PATCH] Debian packaging for 0.99.4 [u]
On Thursday 11 August 2005 23:53, Linus Torvalds wrote: Hands up people. Does anybody _use_ GNU interactive tools? None of this I have a package crap. http://popcon.debian.org/by_inst #Format # #name is the package name; #inst is the number of people who installed this package; #vote is the number of people who use this package regularly; #old is the number of people who installed, but don't use this package # regularly; #recent is the number of people who upgraded this package recently; #no-files is the number of people whose entry didn't contain enough # information (atime and ctime were 0). #rank nameinst vote old recent no-files 6607 git 1142582 7 0 the database reflects 7162 users. Andreas - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi, Alan Chandler wrote: Not sure I understand the proper use of dpkg-divert in Debian, but could _this_ git-core package perhaps ask the user which set of the two packages he wish to keep as git command and use dpkg-divert to change the other to another name to some other name? IIRC, that's against Policy too, because different users on the system might have different expectations WRT which git is git. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - You have a strong appeal for members of the opposite sex. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi, David Lang: after so many years of software development (and with the policy of never having conflicting command names) what three letter combinations are still avilable? Lots. I'm assuming that the much smaller pool of two letter commands was long since exhausted, but if not what two letter commands are available? Lots of them, I hope, but all of them obscure. We even have 25 one-letter commands that are free. My /usr/bin/ only has 'w'. And if we run out, we could branch off into other alphabets; unfortunately, not everybody has a quick way to type an ä. Or α. Or ૐ. ;-) -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - The hope that springs eternal Springs right up your behind. -- Ian Drury, This Is What We Find signature.asc Description: Digital signature
git reveals a bug in (some versions) BSD diff
Hi, big was my surprise when my daily routine of git pull make test failed. git bisect revealed that commit 8e832e: String comparison of test is done with '=', not '=='. was the culprit. But it isn't. The version of diff present on my iBook (OS 10.2.8) does not work properly in this case: (echo a; echo b | tr -d '\012') frotz.2 (echo a; echo c; echo b | tr -d '\012') frotz.3 diff -u frotz.2 frotz.3 yields --- a1 2005-08-12 14:24:19.0 +0200 +++ a2 2005-08-12 14:24:27.0 +0200 @@ -1,2 +1,3 @@ a +c b Note the missing \ No newline at end of file. The same happens on sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2 server. How to go about that? Silently ignore the missing line in apply.c? Force users to update their diff to a sane version? Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add --sign option to git-format-patch-script
This adds the option --sign to git-format-patch-script which adds a Signed-off-by: line automatically. Signed-off-by: Johannes Schindelin [EMAIL PROTECTED] --- git-format-patch-script | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) a72d370d43c397238a26c1c7f260a3fd6401f4e6 diff --git a/git-format-patch-script b/git-format-patch-script --- a/git-format-patch-script +++ b/git-format-patch-script @@ -6,7 +6,7 @@ . git-sh-setup-script || die Not a git archive. usage () { -echo 2 usage: $0' [-n] [-o dir] [--mbox] [--check] [-diff options...] upstream [ our-head ] +echo 2 usage: $0' [-n] [-o dir] [--mbox] [--check] [--sign] [-diff options...] upstream [ our-head ] Prepare each commit with its patch since our-head forked from upstream, one file per patch, for e-mail submission. Each output file is @@ -46,6 +46,8 @@ do date=t author=t mbox=t ;; -n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered) numbered=t ;; +-s|--s|--si|--sig|--sign) +signoff=t ;; -o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\ --output-d=*|--output-di=*|--output-dir=*|--output-dire=*|\ --output-direc=*|--output-direct=*|--output-directo=*|\ @@ -174,6 +176,14 @@ Date: '$ad b body' sed -ne $mailScript $commsg + + test $signoff = t { + offsigner=`git-var GIT_COMMITTER_IDENT | sed -e 's/.*//'` + echo + echo Signed-off-by: $offsigner + echo + } + echo '---' echo git-diff-tree -p $diff_opts $commit | git-apply --stat --summary - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Clean generated files a bit more.
Petr Baudis [EMAIL PROTECTED] writes: This makes me a bit nervous - why are you making the rules more general? make clean removing random tarballs of mine happenning to dwell in that directory is fearsome. That is a valid concern. I'd drop that *.tar.gz part at least and probably the *.deb *.dsc part as well. Thanks for sanity checking. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use -script postfix for scripts
Johannes Schindelin [EMAIL PROTECTED] writes: For consistency reasons, the names of all scripts should end in -script. This may be a bit controversial (people might find it unnecessary). Subject to discussion. 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. And to cope with long names and make things look a bit more familiar to CVS migrants, git wrapper was invented to supply the -script suffix to grok git whatever, but just in case if something was _not_ implemented as a script, it ends up needing to try git-whatever in addition to git-whatever-script. The patch alleviates the git problem for git-whatchanged and friends whose names currently do not end with -script, but it still does not help git apply, for example. I like the general direction of making things consistent, but I wonder if we can become consistent by losing -script suffix, not adding to the ones that lack it. And as you imply, this kind of change inevitable breaks people's scripts. But I do agree with you that we should do something about it, so it may be better to break them sooner rather than later, as long as we make sure we break them just once. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add --sign option to git-format-patch-script
Good intentions, but I'd rather see these S-O-B lines in the actual commit objects. Giving format-patch this option would discourage people to do so. Maybe a patch to git commit would be more appropriate, methinks. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use -script postfix for scripts
hI, On Fri, 12 Aug 2005, Junio C Hamano wrote: Johannes Schindelin [EMAIL PROTECTED] writes: For consistency reasons, the names of all scripts should end in -script. This may be a bit controversial (people might find it unnecessary). Subject to discussion. I have never liked the original -script name convention. Okay. I'm all for dropping the -script postfix. Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add --sign option to git-format-patch-script
Hi, On Fri, 12 Aug 2005, Junio C Hamano wrote: Good intentions, but I'd rather see these S-O-B lines in the actual commit objects. Giving format-patch this option would discourage people to do so. Maybe a patch to git commit would be more appropriate, methinks. Maybe in addition to this one? I meant that option to be for on-passers of commits they are not author of. Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git reveals a bug in (some versions) BSD diff
Johannes Schindelin [EMAIL PROTECTED] writes: I'd prefer to deprecate that diff program by telling so in the test. Something along the lines blabla. If this fails, chances are you have a borked diff. Try GNU diff... Wouldn't it give the people with broken diff a false impression that their git diff actually produces a good result when it does not? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch-pack: start multi-head pulling.
Johannes Schindelin [EMAIL PROTECTED] writes: I seem to remember Junio does not like bash arrays... And in a recent commit message, he even admits to using something different than bash! Correct and somewhat misleading. My usual shell is bash but from time to time I try to run things with (d)ash to see how far I strayed from the common denominator. Yes, I am old fashioned. I have been trying, admittably perhaps not very successfully, to stay away from bashism in the core GIT scripts. I knew we started using shell array when Linus did the git-diff-script, but I have been hoping somebody coming from other platforms (hello, Solaris and Darwin guys) would send in patches if they cared enough. So I try to avoid making their life harder than already is. Here is a semi off-topic joke, hopefully to give you a better sense of where I am coming from. Anybody can start pretending to be an old fashioned shell programmer by adhering to the following simple rules: 1. Never, ever say [ ... ]; we old-timers always spell that test. 2. Never use test when case would do; this comes from the days when test was not built-in and machines were small. We tried to reduce number of forks in our scripts. We also never use echo piped to grep when case would do. 3. We tend to write || more often than we use if ... then ... fi, especially for simple things. We do not use parantheses () to introduce command grouping lightly. We usually say braces {} and use parentheses only when we do want a subshell. 4. Say ${var-default} more often than ${var:-default}; colon form is more recent invention, and we old-timers tend to be more careful to consider the possibility that, when a user says this variable is empty, the user really means it. 5. We are still allowed to use $() form in preference to ``, because it is clearly superior (it can nest) and should have been the way to spell it from the beginning. -jc - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Matthias Urlichs [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout -f branch doesn't remove extra files
Luck, Tony [EMAIL PROTECTED] writes: I see that when I switch view to a different branch with: $ git checkout -f someoldbranch that any files that exist in my previous branch view but not in someoldbranch are not deleted. ... I wondered whether this was a deliberate choice Not really. When possible, please use git checkout without -f. That form uses git-read-tree -u -m, which can tell from your current index file what's changed and what's going away. This is only possible if read-tree can rely on what is in your index file actually matches the status of your working tree, and the -f flag to checkout is to work around cases where you cannot give that guarantee to read-tree and would want/need to start over from scratch. With -f flag, you are telling git-read-tree to ignore what is currently recorded in your index file, hence what should be in your working tree before checkout. There is no way for git-read-tree to tell which are source files that exist only in the old thing you had checked out before (i.e. should be removed) and which are files your build procedure left and/or files you made by hand outside of SCM control (i.e. should be kept) without that information, so that is why those files were left behind. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitweb - feature request
On Wed, Aug 10, 2005 at 06:53:40AM +0100, Ian Campbell wrote: On Tue, 2005-08-09 at 21:58 +0200, Kay Sievers wrote: I was hoping people that want stuff like this would use a RSS reader. :) 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. Has this been fixed or was it something I was doing wrong? It's 30 now and up to 150 if they are not older than 48 hours. We can tweak the numbers if you like to have it different... Kay - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
Wolfgang Denk [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
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* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitweb - feature request
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix documentation installation
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 [EMAIL PROTECTED] --- commit e7b483b293fb7d359dcebf974e6784f8b14f2ab1 tree 5e998614a0dbce85758de5be847306837953bb42 parent 2b0289c3805d0c99eb031a7116948a3cb4ddf332 author Petr Baudis [EMAIL PROTECTED] Fri, 12 Aug 2005 22:58:13 +0200 committer Petr Baudis [EMAIL PROTECTED] 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: - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix documentation installation
Dear diary, on Fri, Aug 12, 2005 at 11:11:45PM CEST, I got a letter where Petr Baudis [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Disc space - the final frontier! - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
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* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
- 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT?] git tools at SourceForge ?
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] more Debian packaging fixes
git-tk should be architecture independent. git-core forgot to depend on perl. Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED] --- Hi, Junio C Hamano: Matthias Urlichs [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Cloning speed comparison
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-pull660s cogito clone-pack:ssh 35s (!) cogito rsync 140s cogito ssh-pull480s 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-pull120s (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://[EMAIL PROTECTED]/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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cloning speed comparison
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cloning speed comparison
Dear diary, on Sat, Aug 13, 2005 at 04:12:26AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
On Fri, Jul 29, 2005 at 08:10:51AM +, Petr Baudis wrote: Exactly. I want much more freedom in pushing, the only requirement being that the to-be-replaced remote head is ancestor of the to-be-pushed local head. I think (am I wrong?) git-send-pack localhead:remotehead would work just fine for me, the only thing I need is the support for different local and remote head names. Greetings, Sorry to join the game so late. I've only read this thread now. It seems to me that this is the way to go. Several have mentioned that head names should be the same on the remote and the local side. However, I wanted to point out that it may be impossible to keep these names in sync due to the 'loosely knit' nature of the types of projects that are likely to use git. It seems that the requirement that the remote head be a strict ancestor of the local head is actually quite strong and should avoid mistakes like pushing to the wrong head. Anyway, those are my two cents. I couldn't tell wether a resolution had been achieved so I thought I would pipe up. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cloning speed comparison
Petr Baudis wrote: 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.) Yes, when I get some time... -hpa - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cloning speed comparison
On Fri, 12 Aug 2005, H. Peter Anvin wrote: Running it over ssh would be a good way to do authentication... Well, if you have ssh as an option, you don't need git-daemon any more, since the protocol that git-daemon does runs quite well over ssh on its own... The only point of git-daemon really is when you don't have ssh access (ie you may want to give people a limited interface, but not full ssh). Ie as-is, it's only for anonymous reads of a git archive, but it obviously _could_ do more. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: git checkout -f branch doesn't remove extra files
On Fri, Aug 12, 2005 at 10:05:11PM -0700, Linus Torvalds wrote: HOWEVER, if all you want to do is just a tar-file, then there's a better solution. It's called snap=git-snapshot-$(date +%Y%m%d) git-tar-tree HEAD $snap | gzip -9 $snap.tar.gz which is even easier, and a hell of a lot more efficient. Nice. That takes noticably less time to create the sparse/git snapshots compared to my crappy old script. And its now less than half the size. I'm sold. Git actually has a _lot_ of nifty tools. I didn't realize that people didn't know about such basic stuff as git-tar-tree and git-ls-files. Maybe its because things are moving so fast :) Or maybe I just wasn't paying attention on that day. (I even read the git changes via RSS, so I should have no excuse). Dave - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: git checkout -f branch doesn't remove extra files
On Sat, 13 Aug 2005, Dave Jones wrote: Git actually has a _lot_ of nifty tools. I didn't realize that people didn't know about such basic stuff as git-tar-tree and git-ls-files. Maybe its because things are moving so fast :) Or maybe I just wasn't paying attention on that day. (I even read the git changes via RSS, so I should have no excuse). Well, git-tar-tree has been there since late April - it's actually one of those really early commands. I'm pretty sure the RSS feed came later ;) I use it all the time in doing releases, it's a lot faster than creating a tar tree by reading the filesystem (even if you don't have to check things out). A hidden pearl. This is my crappy release-script: [EMAIL PROTECTED] ~]$ cat bin/release-script #!/bin/sh stable=$1 last=$2 new=$3 echo # git-tag-script v$new echo git-tar-tree v$new linux-$new | gzip -9 ../linux-$new.tar.gz echo git-diff-tree -p v$stable v$new | gzip -9 ../patch-$new.gz echo git-rev-list --pretty v$new ^v$last ../ChangeLog-$new echo git-rev-list --pretty=short v$new ^v$last | git-shortlog ../ShortLog echo git-diff-tree -p v$last v$new | git-apply --stat ../diffstat-$new and when I want to do a new kernel release I literally first tag it, and then do release-script 2.6.12 2.6.13-rc6 2.6.13-rc7 and check that things look sane, and then just cut-and-paste the commands. Yeah, it's stupid. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html