Re: [PATCH] Debian packaging for 0.99.4 [u]

2005-08-12 Thread Andreas Jellinghaus [c]
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

2005-08-12 Thread Matthias Urlichs
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

2005-08-12 Thread Matthias Urlichs
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

2005-08-12 Thread Johannes Schindelin
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

2005-08-12 Thread Johannes Schindelin
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.

2005-08-12 Thread Junio C Hamano
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

2005-08-12 Thread Junio C Hamano
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

2005-08-12 Thread Junio C Hamano
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

2005-08-12 Thread Johannes Schindelin
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

2005-08-12 Thread Johannes Schindelin
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

2005-08-12 Thread Junio C Hamano
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.

2005-08-12 Thread Junio C Hamano
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

2005-08-12 Thread 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?

-
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

2005-08-12 Thread Junio C Hamano
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

2005-08-12 Thread Kay Sievers
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 ?

2005-08-12 Thread Junio C Hamano
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 ?

2005-08-12 Thread Daniel Barkalow
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 ?

2005-08-12 Thread Kirby C. Bohling
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

2005-08-12 Thread Mitchell Blank Jr
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

2005-08-12 Thread Petr Baudis
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

2005-08-12 Thread Petr Baudis
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 ?

2005-08-12 Thread Marco Costalba
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 ?

2005-08-12 Thread Wolfgang Denk
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 ?

2005-08-12 Thread Linus Torvalds


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 ?

2005-08-12 Thread Martin Langhoff
  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 ?

2005-08-12 Thread Daniel Barkalow
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 ?

2005-08-12 Thread Martin Langhoff
  - 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 ?

2005-08-12 Thread Linus Torvalds


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

2005-08-12 Thread Matthias Urlichs
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

2005-08-12 Thread Petr Baudis
  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

2005-08-12 Thread Linus Torvalds


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

2005-08-12 Thread Petr Baudis
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)?

2005-08-12 Thread Carl Baldwin
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

2005-08-12 Thread H. Peter Anvin

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

2005-08-12 Thread Linus Torvalds


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

2005-08-12 Thread Dave Jones
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

2005-08-12 Thread Linus Torvalds


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