* Re: cg-clone produces "___" file and no working tree
From: Petr Baudis @ 2006-04-19 14:48 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20060419142131.GD4104@tumblerings.org>
Hi,
Dear diary, on Wed, Apr 19, 2006 at 04:21:31PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> said that...
> On Wed, Apr 19, 2006 at 11:49:16AM +0200, Petr Baudis wrote:
> > Dear diary, on Wed, Apr 19, 2006 at 07:36:40AM CEST, I got a letter
> > where Zack Brown <zbrown@tumblerings.org> said that...
> > > When I do something like
> > > cg-clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
> > >
> > > The first few lines of output are:
> > >
> > > defaulting to local storage area
> > > warning: templates not found /home/zbrown/share/git-core/templates/
> > > /home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
> > > /home/zbrown/git/cogito/cg-clone: line 148: .git/info/cg-fetch-initial: No such file or directory
> > >
> > > The rest of the process seems to go without incident. However, when I look
> > > at the repository I see:
> > >
> > > $ ls -A
> > > .git ___
> > > $
> >
> > Could you please list the contents of the .git subdirectory? It seems
> > that git-init-db did not create the .git/info subdirectory.
>
> 07:19:57 [zbrown] ~/git/trees/tmp/git/.git$ ls -F
> total 28
> 4 HEAD 4 branches/ 4 config 4 index 4 info/ 4 objects/ 4 refs/
hmm, could you please do this just after running git-init-db in an
empty directory? I just realized cg-fetch will mkdir -p the .git/info/
directory.
If the .git/info/ directory would be there after git-init-db, I
couldn't explain the
/home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
error. If the .git/info/ directory is not there after git-init-db,
either it is somehow broken in git-1.3.0, or it belongs to a much older
git version.
> 07:18:38 [zbrown] ~$ which git-init-db
> /home/zbrown/git/git//git-init-db
> 07:18:52 [zbrown] ~$ which git
> /home/zbrown/git/git//git
It might be a good idea to compare the ctimes.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 14:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <4445F1B0.4060105@op5.se>
On Wed, 19 Apr 2006, Andreas Ericsson wrote:
>
> Except that you'll have to explicitly state HEAD:pathname:with:colon, or does
> it try finding a file with the argument verbatim first?
If you have a pathname:with:colon and you _just_ want to use it as a
pathname, you'd do one of either:
- use "--" to separate the pathnames from the revision info. That always
works.
- even without the "--", if the first part of the pathname:with:colon (ie
the "pathname" part) cannot be looked up as a SHA1 tag, then the
pathname:with:colon is left alone and seen as a normal file.
So "--" is always the dis-ambiguator. But it almost certainly will never
be needed.
Linus
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Zack Brown @ 2006-04-19 14:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060419094916.GD27689@pasky.or.cz>
Hi Petr,
On Wed, Apr 19, 2006 at 11:49:16AM +0200, Petr Baudis wrote:
> Dear diary, on Wed, Apr 19, 2006 at 07:36:40AM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> said that...
> > When I do something like
> > cg-clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
> >
> > The first few lines of output are:
> >
> > defaulting to local storage area
> > warning: templates not found /home/zbrown/share/git-core/templates/
> > /home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
> > /home/zbrown/git/cogito/cg-clone: line 148: .git/info/cg-fetch-initial: No such file or directory
> >
> > The rest of the process seems to go without incident. However, when I look
> > at the repository I see:
> >
> > $ ls -A
> > .git ___
> > $
>
> Could you please list the contents of the .git subdirectory? It seems
> that git-init-db did not create the .git/info subdirectory.
07:19:57 [zbrown] ~/git/trees/tmp/git/.git$ ls -F
total 28
4 HEAD 4 branches/ 4 config 4 index 4 info/ 4 objects/ 4 refs/
>
> I suspect that something went wrong with your installation and in fact
> you are using much older git version. Check git --version and if `which
> git-init-db` corresponds to `which git`.
07:11:13 [zbrown] ~$ git --version
git version 1.3.0.g2473-dirty
07:18:38 [zbrown] ~$ which git-init-db
/home/zbrown/git/git//git-init-db
07:18:52 [zbrown] ~$ which git
/home/zbrown/git/git//git
07:18:54 [zbrown] ~$
I assume the "-dirty" in the version number means it thinks I've made some
changes, but I really haven't. Maybe the repo got corrupted somehow.
Be well,
Zack
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> Right now I am having amnesia and deja-vu at the same time. I think
> I have forgotten this before.
--
Zack Brown
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Zack Brown @ 2006-04-19 14:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5feawel.fsf@assigned-by-dhcp.cox.net>
On Tue, Apr 18, 2006 at 11:53:38PM -0700, Junio C Hamano wrote:
> Zack Brown <zbrown@tumblerings.org> writes:
>
> > What is going on? I'm completely unable to clone a repository.
>
> I have no idea how cg-* is broken, so I'll let Pasky answer
> that, but I suspect your git installation is broken.
>
> > If I try
> > "git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git",
> > I get this error: "git: 'clone' is not a git-command", and it prints a usage
> > page, but "clone" is listed on that usage page.
>
> That sounds intersting. Although rsync is deprecated for a long
> time and git:// is the preferred transport, I do not get "is not
> a git-command" error. Are you installing things correctly?
I think so. I was able to reproduce this behavior using the tarballs that are
used to start out a new user with git and cogito; as well as with the latest
version in the repository.
But I also thought the rsync deprecation was not really true. Wasn't that
discussed here recently? I thought the conclusion was that folks *wanted*
to deprecate it, but at the moment it was still the best way to accomplish
certain things.
>
> For example, as the first paragraph of INSTALL says, if you
> override prefix= from the make command line, you need to do so
> consistently when you build and when you install.
>
> What do these command say?
>
> $ git --exec-path
> $ ls -l "`git --exec-path`/git-clone"
22:07:05 [zbrown] ~$ git --exec-path
/home/zbrown/bin
07:10:34 [zbrown] ~$ ls -l "`git --exec-path`/git-clone"
ls: /home/zbrown/bin/git-clone: No such file or directory
Does that mean it's looking in /home/zbrown/bin for the git binaries? That's
weird. I have /home/zbrown/git/git and /home/zbrown/git/cogito in my $PATH
specifically to hold those executables. There's no git stuff in
/home/zbrown/bin.
Be well,
Zack
>
--
Zack Brown
^ permalink raw reply
* git-daemon memory usage, disconnection.
From: David Woodhouse @ 2006-04-19 13:22 UTC (permalink / raw)
To: git
I'm running git-daemon from xinetd and it seems a little greedy...
Cpu(s): 2.7% us, 6.4% sy, 0.0% ni, 1.7% id, 87.7% wa, 1.4% hi, 0.0% si
Mem: 253680k total, 250076k used, 3604k free, 568k buffers
Swap: 500960k total, 500864k used, 96k free, 24696k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31232 nobody 18 0 155m 29m 7224 D 1.3 11.9 0:25.56 git-rev-list
30743 nobody 18 0 179m 29m 9480 D 0.7 11.9 0:42.60 git-rev-list
31277 nobody 18 0 147m 28m 7476 D 2.6 11.4 0:20.90 git-rev-list
30314 nobody 18 0 233m 26m 7696 D 0.0 10.6 1:20.24 git-rev-list
30612 nobody 18 0 204m 23m 7432 D 1.3 9.4 0:59.19 git-rev-list
30574 nobody 18 0 190m 20m 7608 D 0.3 8.3 0:50.77 git-rev-list
30208 nobody 18 0 140m 14m 7632 D 0.3 5.9 0:15.23 git-pack-object
Now, this wouldn't be _so_ bad if there were only two of them running.
The clients for the other four have actually given up and disconnected
long ago, but git-daemon doesn't seem to have reacted to that.
--
dwmw2
^ permalink raw reply
* Default refspec for branches
From: Josh Boyer @ 2006-04-19 12:58 UTC (permalink / raw)
To: git
Is there a way to change the default refspec that git pull uses on a
per branch basis? I know that you can create .git/remotes/<foo> and
do 'git pull <foo>' to pull from whatever is listed in there, but that
isn't quite what I'm looking for.
What I'd like to be able to do is create a branch and have 'git pull'
simply pull from the remote tree. I tried listing multiple refspecs
in .git/remotes/origin, but git didn't seem to like that.
For example, I clone Linus' tree. Then I create a branch called mtd.
When I'm working in that branch, I want 'git pull' to pull from
git://git.infradead.org/mtd-2.6.git.
Any ideas?
josh
^ permalink raw reply
* Re: GIT Error issue
From: Erik Mouw @ 2006-04-19 11:21 UTC (permalink / raw)
To: Shyamal Sadanshio; +Cc: git
In-Reply-To: <3857255c0604190416j62abeae8va164896c5100f6ee@mail.gmail.com>
On Wed, Apr 19, 2006 at 04:46:57PM +0530, Shyamal Sadanshio wrote:
> I am newbie to GIT and facing some problem with the GIT usage. I am
> trying to clone a repository at www.linux-mips.org with the
> following command, I get error message as below:
>
> **************************************************************************
> [root@sshyamal git-tutorial]# git clone
> git://ftp.linux-mips.org/pub/scm/linux-malta.git linux-malta.git
> git: warning: invalid extra options ignored
>
> GNU Interactive Tools 4.3.20 (i686-pc-linux-gnu), 12:39:46 Apr 18 2006
> GIT is free software; you can redistribute it and/or modify it under the
> terms of the GNU General Public License as published by the Free
> Software
> Foundation; either version 2, or (at your option) any later version.
> Copyright (C) 1993-1999 Free Software Foundation, Inc.
> Written by Tudor Hulubei and Andrei Pitis, Bucharest, Romania
>
> git: fatal error: `chdir' failed: permission denied.
You're using the wrong GIT. Remove the GNU Interactive Tools and use
git from kernel.org.
> ***************************************************************************
>
> I am exercising this command in root mode.
There is absolutely zero reason to run git as root.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: GIT Error issue
From: Krzysiek Pawlik @ 2006-04-19 11:20 UTC (permalink / raw)
To: Shyamal Sadanshio; +Cc: git
In-Reply-To: <3857255c0604190416j62abeae8va164896c5100f6ee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
Shyamal Sadanshio wrote:
> **************************************************************************
> [root@sshyamal git-tutorial]# git clone
> git://ftp.linux-mips.org/pub/scm/linux-malta.git linux-malta.git
> git: warning: invalid extra options ignored
>
> GNU Interactive Tools 4.3.20 (i686-pc-linux-gnu), 12:39:46 Apr 18 2006
^ ^ ^
Use git - the content manager, not interactive tools. Use full path to
git executable.
--
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: GIT Error issue
From: Sam Ravnborg @ 2006-04-19 11:20 UTC (permalink / raw)
To: Shyamal Sadanshio; +Cc: git
In-Reply-To: <3857255c0604190416j62abeae8va164896c5100f6ee@mail.gmail.com>
On Wed, Apr 19, 2006 at 04:46:57PM +0530, Shyamal Sadanshio wrote:
> Hi,
>
> I am newbie to GIT and facing some problem with the GIT usage. I am
> trying to clone a repository at www.linux-mips.org with the
> following command, I get error message as below:
>
> **************************************************************************
> [root@sshyamal git-tutorial]# git clone
> git://ftp.linux-mips.org/pub/scm/linux-malta.git linux-malta.git
> git: warning: invalid extra options ignored
>
> GNU Interactive Tools 4.3.20 (i686-pc-linux-gnu), 12:39:46 Apr 18 2006
You are running the wrong git.
The git you are running are the "GNU Interactive Tools" and not git from
the git-suite.
Fix - uninstall "GNU Interactive Tools"
Sam
^ permalink raw reply
* GIT Error issue
From: Shyamal Sadanshio @ 2006-04-19 11:16 UTC (permalink / raw)
To: git
Hi,
I am newbie to GIT and facing some problem with the GIT usage. I am
trying to clone a repository at www.linux-mips.org with the
following command, I get error message as below:
**************************************************************************
[root@sshyamal git-tutorial]# git clone
git://ftp.linux-mips.org/pub/scm/linux-malta.git linux-malta.git
git: warning: invalid extra options ignored
GNU Interactive Tools 4.3.20 (i686-pc-linux-gnu), 12:39:46 Apr 18 2006
GIT is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free
Software
Foundation; either version 2, or (at your option) any later version.
Copyright (C) 1993-1999 Free Software Foundation, Inc.
Written by Tudor Hulubei and Andrei Pitis, Bucharest, Romania
git: fatal error: `chdir' failed: permission denied.
***************************************************************************
I am exercising this command in root mode.
I have browsed through FAQs/archived mails but haven't come across
appropriate solution to this.
Can anyone please let me know the problem cause for this issue?
Thanks and Regards,
Shyamal
^ permalink raw reply
* Re: Next problem: empty ident <joern@limerick.(none)> not allowed
From: Petr Baudis @ 2006-04-19 9:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jörn Engel, git
In-Reply-To: <7vr73uei1w.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Apr 18, 2006 at 10:37:47PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
>
> > And now I have some questions:
> > 1. Why didn't the environment variables work?
> > 2. Why is there a check for commit information when I pull from some
> > tree?
>
> Because "pull" means "fetch and merge the local modifications if
> any". When you merge (and you _did_ merge), you create a new
> commit of your own, and the commit records who committed it.
>
> You need GIT_COMMITTER_EMAIL.
You mean GIT_COMMITTER_NAME. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Petr Baudis @ 2006-04-19 9:49 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20060419053640.GA16334@tumblerings.org>
Dear diary, on Wed, Apr 19, 2006 at 07:36:40AM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> said that...
> When I do something like
> cg-clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
>
> The first few lines of output are:
>
> defaulting to local storage area
> warning: templates not found /home/zbrown/share/git-core/templates/
> /home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
> /home/zbrown/git/cogito/cg-clone: line 148: .git/info/cg-fetch-initial: No such file or directory
>
> The rest of the process seems to go without incident. However, when I look
> at the repository I see:
>
> $ ls -A
> .git ___
> $
Could you please list the contents of the .git subdirectory? It seems
that git-init-db did not create the .git/info subdirectory.
I suspect that something went wrong with your installation and in fact
you are using much older git version. Check git --version and if `which
git-init-db` corresponds to `which git`.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Clone with local alternates?
From: Eric W. Biederman @ 2006-04-19 9:42 UTC (permalink / raw)
To: David Woodhouse; +Cc: Shawn Pearce, git
In-Reply-To: <1145435957.13200.39.camel@pmac.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> On Tue, 2006-04-18 at 19:56 -0400, Shawn Pearce wrote:
>> git clone --reference=/foo git://remote/foo
>
> That's nice. What would be even _nicer_ is if I could enforce its usage
> on the server. I keep a clean copy of Linus' kernel tree on the machine
> with the git dæmon, so I'd like to make it refuse to send any objects
> which are in that tree and which people should already have fetched from
> elsewhere anyway.
Given how large the linux kernel archive is I can see the desire.
At git startup there is an exchange of common commits. to
find the best place to build the pack from so what you want
is possible. I haven't a clue how you would describe it
though in the face of multiple branches, coming off the
trunk at different times.
Eric
^ permalink raw reply
* Re: Clone with local alternates?
From: Eric W. Biederman @ 2006-04-19 9:36 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1145404132.16166.97.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> Often I want to clone a remote repository but would like to use an
> existing local source tree as 'alternates'.
>
> One way of doing this is to clone the local tree with 'git-clone -l -s',
> find the latest common commit shared with the remote tree to be fetched,
> revert to that with 'git-reset --head $last' and then pulling from the
> remote.
Simpler than the git-reset you can simply do
git-fetch remote branch:branch and git will find common ancestor
for you and create a new branch that mirrors the old one.
I mention this because it can be interesting to have branches
from several remote repositories all in one local repository.
Eric
^ permalink raw reply
* Re: Clone with local alternates?
From: David Woodhouse @ 2006-04-19 8:39 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060418235658.GB8915@spearce.org>
On Tue, 2006-04-18 at 19:56 -0400, Shawn Pearce wrote:
> git clone --reference=/foo git://remote/foo
That's nice. What would be even _nicer_ is if I could enforce its usage
on the server. I keep a clean copy of Linus' kernel tree on the machine
with the git dæmon, so I'd like to make it refuse to send any objects
which are in that tree and which people should already have fetched from
elsewhere anyway.
--
dwmw2
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Andreas Ericsson @ 2006-04-19 8:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604181745410.3701@g5.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 18 Apr 2006, Linus Torvalds wrote:
>
>>And I thought we already disallowed ':' in branch names because cogito
>>uses them for the strange <rev>:<rev> syntax..
>
>
> Btw, pathnames with ':' in them aren't a problem. It's only revision
> names that can't have ':' in them and still be used together with this
> syntax.
>
> If you have a pathname with ':', it's fine to do
>
> git cat-file v1.2.4:pathname:with:colon
>
> because the magic revision parsing only cares about the _first_ colon, and
> will split that into "v1.2.4" and "pathname:with:colon" without ever even
> looking at the other ones.
>
Except that you'll have to explicitly state HEAD:pathname:with:colon, or
does it try finding a file with the argument verbatim first?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Junio C Hamano @ 2006-04-19 6:53 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20060419053640.GA16334@tumblerings.org>
Zack Brown <zbrown@tumblerings.org> writes:
> What is going on? I'm completely unable to clone a repository.
I have no idea how cg-* is broken, so I'll let Pasky answer
that, but I suspect your git installation is broken.
> If I try
> "git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git",
> I get this error: "git: 'clone' is not a git-command", and it prints a usage
> page, but "clone" is listed on that usage page.
That sounds intersting. Although rsync is deprecated for a long
time and git:// is the preferred transport, I do not get "is not
a git-command" error. Are you installing things correctly?
For example, as the first paragraph of INSTALL says, if you
override prefix= from the make command line, you need to do so
consistently when you build and when you install.
What do these command say?
$ git --exec-path
$ ls -l "`git --exec-path`/git-clone"
^ permalink raw reply
* cg-clone produces "___" file and no working tree
From: Zack Brown @ 2006-04-19 5:36 UTC (permalink / raw)
To: git
Hi folks,
I'm experiencing a problem that seems like it must be my fault, but I
can't figure it out. I'm using cogito-0.17.2-ga543f4f and git version
1.3.0.g2473-dirty.
When I do something like
cg-clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
The first few lines of output are:
defaulting to local storage area
warning: templates not found /home/zbrown/share/git-core/templates/
/home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
/home/zbrown/git/cogito/cg-clone: line 148: .git/info/cg-fetch-initial: No such file or directory
The rest of the process seems to go without incident. However, when I look
at the repository I see:
$ ls -A
.git ___
$
Then when I cat the "___" file, I see:
$ cat ___
This is a clone-in-progress GIT working tree containing a GIT repository
in the .git subdirectory. If you see this file and noone is fetching or
cloning in this repository, the clone has been interrupted; you can restart
it by issuing this command (it's enough as-is):
cg-fetch
$
I give the "cg-fetch" command as instructed, but it seems to have no effect,
and the "___" file remains unchanged.
What is going on? I'm completely unable to clone a repository. If I try
"git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git",
I get this error: "git: 'clone' is not a git-command", and it prints a usage
page, but "clone" is listed on that usage page.
I don't know what to make of this, and I don't see any other discussion of this
problem, so I assume it's my own fault, but I don't see what I might have done
wrong.
Be well,
Zack
--
Zack Brown
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Junio C Hamano @ 2006-04-19 5:00 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4445C1D6.3070504@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Jörn Engel wrote:
>>
>> Excellent! I have a faint memory of hpa recently saying that the git
>> daemon would be too resource-hungry. One of the cases where being
>> wrong is a Good Thing.
>
> Well, we ended up making some tweaks to the git daemon, and it hasn't
> been a problem since.
Ah, I am glad the daemon expert was listening... Do you have
comments on recent patch from Serge E. Hallyn? It looks OK to
me, but that standalone daemon part is not something I run
myself, so...
-- >8 --
[PATCH] socksetup: don't return on set_reuse_addr() error
The set_reuse_addr() error case was the only error case in
socklist() where we returned rather than continued. Not sure
why. Either we must free the socklist, or continue. This patch
continues on error.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
daemon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
0032d548db56eac9ea09b4ba05843365f6325b85
diff --git a/daemon.c b/daemon.c
index a1ccda3..776749e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -535,7 +535,7 @@ #endif
if (set_reuse_addr(sockfd)) {
close(sockfd);
- return 0; /* not fatal */
+ continue;
}
if (bind(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
--
1.3.0.rc4.g5247-dirty
^ permalink raw reply related
* Re: GIT_OBJECT_DIRECTORY
From: H. Peter Anvin @ 2006-04-19 4:51 UTC (permalink / raw)
To: Jörn Engel; +Cc: Linus Torvalds, git
In-Reply-To: <20060418182650.GB25688@wohnheim.fh-wedel.de>
Jörn Engel wrote:
> On Tue, 18 April 2006 11:08:40 -0700, Linus Torvalds wrote:
>> On Tue, 18 Apr 2006, Jörn Engel wrote:
>>>> git clone git://git.kernel.org/... foo/
>>> Is it possible for non-owners of a kernel.org account to do this?
>> Yes, kernel.org runs the git daemon.
>
> Excellent! I have a faint memory of hpa recently saying that the git
> daemon would be too resource-hungry. One of the cases where being
> wrong is a Good Thing.
>
Well, we ended up making some tweaks to the git daemon, and it hasn't
been a problem since.
-hpa
^ permalink raw reply
* Re: Fix uninteresting tags in new revision parsing
From: Junio C Hamano @ 2006-04-19 4:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604182027460.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> When I unified the revision argument parsing, I introduced a simple bug
> wrt tags that had been marked uninteresting. When it was preparing for the
> revision walk, it would mark all the parent commits of an uninteresting
> tag correctly uninteresting, but it would forget about the commit itself.
Thanks. Can't believe I missed it...
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 4:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xq2ciws.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 Apr 2006, Junio C Hamano wrote:
>
> A small fry in the ointment. What should the parts that are
> output with --name-only say for such a diff?
I have no idea, I have to say ;)
> Blob references like v0.99.6:git-commit-script are resolved by
> the extended SHA1 interpreter, and all what the caller of
> setup_revisions() can see and feed the diff machinery with has
> are their object names.
Actually, the names are there. The object list has the "->name" field
(used to do the name-based sorting), and we actually even fill it in for
the stuff we pass in as arguments. See the "add_pending_object()" calls
in setup_revisions().
We just don't use them right now. We _could_.
> Something like this is a possibility, but is ugly.
>
> diff --git a/a2455b0... b/01c73bd...
> index a2455b0..01c73bd 100644
> --- a/a2455b0...
> +++ b/01c73bd...
Yes. But if you look at the object list name (in the "pending_object"
thing), you _could_ actually get this to be something like
diff --git v0.99.6:git-commit-script git-commit.sh
index a2455b0..01c73bd 100644
--- v0.99.6:git-commit-script
+++ git-commit.sh
which would be much prettier, although I'm not saying it's necessarily
worth it. I'm just saying that it's _possible_ with the cmd line parsing
infrastructure we have now.
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 4:04 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604182056390.3701@g5.osdl.org>
On Tue, 18 Apr 2006, Linus Torvalds wrote:
>
> And no, I didn't actually test it. But it really _should_ work with that
> trivial diff, including with the "a..b" format.
Ok, tested and verified.
On the kernel:
git diff v2.6.13:drivers/block/..HEAD:block/ -- ll_rw_blk.c
actually does the right thing - it shows the diff for ll_rw_blk.c which
got moved from drivers/block/ into block/ between 2.6.13 and current.
Note that the "--" is required, since ll_rw_blk.c doesn't exist in the
top-level directory where we run the command (but does exist in the git
trees that we have specified manually with the new shorthand).
Linus
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Junio C Hamano @ 2006-04-19 4:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181836400.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Actually, it's not ambiguous. Just take the named file. If you want to
> diff it against HEAD:<named-file>, you should just say so.
>
> Now, if you _really_ want to be difficult, there's a third option: to diff
> it against the named file as named in the index. "git diff" does have the
> "--cached" option that would make that case unambiguous too, of course.
>
> Ie:
>
> (a) diff against the current HEAD:
>
> git diff v0.99.6:git-commit-script HEAD:git-commit.sh
>
> (b) diff against the current index contents for "git-commit.sh":
>
> git diff --cached v0.99.6:git-commit-script git-commit.sh
>
> (c) diff against a random file (which may not even be in the index):
>
> git diff v0.99.6:git-commit-script git-commit.sh
>
> are all sensible operations, and unambiguous.
A small fry in the ointment. What should the parts that are
output with --name-only say for such a diff?
Blob references like v0.99.6:git-commit-script are resolved by
the extended SHA1 interpreter, and all what the caller of
setup_revisions() can see and feed the diff machinery with has
are their object names. Something like this is a possibility,
but is ugly.
diff --git a/a2455b0... b/01c73bd...
index a2455b0..01c73bd 100644
--- a/a2455b0...
+++ b/01c73bd...
@@ -1,118 +1,509 @@
#!/bin/sh
#
# Copyright (c) 2005 Linus Torvalds
+# Copyright (c) 2006 Junio C Hamano
+
+USAGE='[-a] [-s] [-v] [--no-verify] [-m <message>...
+SUBDIRECTORY_OK=Yes
...
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 3:58 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90604182051n4a16ee9atd2577d658befc335@mail.gmail.com>
On Wed, 19 Apr 2006, Martin Langhoff wrote:
>
> <wishlist>
> What about support for diffing a subtree?
>
> git diff v2.2:net/appletalk v2.9:net/appletalk-ng
>
> </whishlist>
Did you try it? It works as-is with that patch. Exactly because it will
call git-diff-tree with the two SHA1's, and since they are now trees (and
not blobs) git-diff-tree will do the right thing.
And no, I didn't actually test it. But it really _should_ work with that
trivial diff, including with the "a..b" format.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox