* [PATCH] Add suggestion to hard-to-understand error message
From: Johannes Schindelin @ 2005-12-21 23:49 UTC (permalink / raw)
To: git, junkio
Dummies like me do not understand readily that "remote object abcdef...
does not exist on local" means: "Hey, you did not pull this, did you?".
So, add "(pull first?)" to that message.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Wow, my commit messages get longer, while the patches get shorter.
Odd.
send-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
af2d86726fe961043d0c69c4fb727689a5903b63
diff --git a/send-pack.c b/send-pack.c
index 5bc2f01..643662a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -233,7 +233,7 @@ static int send_pack(int in, int out, in
!ref->force) {
if (!has_sha1_file(ref->old_sha1)) {
error("remote '%s' object %s does not "
- "exist on local",
+ "exist on local (pull first?)",
ref->name, sha1_to_hex(ref->old_sha1));
ret = -2;
continue;
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] sanity check in add_packed_git()
From: Pavel Roskin @ 2005-12-21 23:47 UTC (permalink / raw)
To: git
add_packed_git() tries to get the pack SHA1 by parsing its name. It may
access uninitialized memory for packs with short names.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/sha1_file.c b/sha1_file.c
index fa22e9c..d83d824 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -464,7 +464,7 @@ struct packed_git *add_packed_git(char *
p->pack_last_used = 0;
p->pack_use_cnt = 0;
p->pack_local = local;
- if (!get_sha1_hex(path + path_len - 40 - 4, sha1))
+ if ((path_len > 44) && !get_sha1_hex(path + path_len - 44, sha1))
memcpy(p->sha1, sha1, 20);
return p;
}
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [OT] western cultural imperialism at vger?
From: David S. Miller @ 2005-12-21 23:46 UTC (permalink / raw)
To: khc; +Cc: junkio, yoshfuji, git
In-Reply-To: <m3oe3ayqa4.fsf@defiant.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Thu, 22 Dec 2005 00:38:27 +0100
> I think (a part of) the above line is in spam filter on vger. They
> use a simple substring match, details are on http://vger.kernel.org.
Right, http://vger.kernel.org/majordomo-taboos.txt
There are content type regexps in there as well as checks
for specific multi-byte character sequences.
^ permalink raw reply
* Re: [OT] western cultural imperialism at vger?
From: Krzysztof Halasa @ 2005-12-21 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: YOSHIFUJI Hideaki / 吉藤英明, git
In-Reply-To: <7v8xue11ag.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> It seems to me that vger drops messages whose content-type is
> "text/plain; charset=iso-2022-jp";
I think (a part of) the above line is in spam filter on vger. They
use a simple substring match, details are on http://vger.kernel.org.
They could probably be able to reject inbound SMTP transfer and not
silently drop the message later.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Junio C Hamano @ 2005-12-21 23:32 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43A9E15F.1060808@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Junio C Hamano wrote:
>> I've pushed out a v1.0.0b maint release to fix a bug in HTTP
>> fetch that was discovered today X-<.
>>
>
> Wouldn't it make more sense for the maintenance release to be 1.0.1?
Maybe. Nobody mentioned this about 0.99.9a, 0.99.9b... though.
The series 1.0.0[a-z] is meant to parallel 2.6.14.[123...]
"fixes only"; OTOH I'd like to allow 1.0.[123...] to contain
enhancements.
^ permalink raw reply
* Re: [OT] western cultural imperialism at vger?
From: David S. Miller @ 2005-12-21 23:29 UTC (permalink / raw)
To: junkio; +Cc: yoshfuji, git
In-Reply-To: <7v8xue11ag.fsf_-_@assigned-by-dhcp.cox.net>
From: Junio C Hamano <junkio@cox.net>
Date: Wed, 21 Dec 2005 15:24:39 -0800
> It seems to me that vger drops messages whose content-type is
> "text/plain; charset=iso-2022-jp"; this western cultural
> imperialism is inexcusable -- the list accepts iso-8859-1 just
> fine, so it is not like it is us-ascii only. It just does not
> like iso-2022-jp.
No, we filter for certain multibyte characters.
If you can teach Matti Aarnio and myself how to speak Japanese,
Korean, Russian, and Chinese, and thus be able to build proper
regexp's for SPAM in those languages, we'll happily do it.
^ permalink raw reply
* Re: [PATCH] GIT: Support [address] in URLs
From: David S. Miller @ 2005-12-21 23:26 UTC (permalink / raw)
To: yoshfuji; +Cc: junkio, git
In-Reply-To: <20051222.080828.28117009.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu, 22 Dec 2005 08:08:28 +0900 (JST)
> In article <7v3bkm3vw4.fsf@assigned-by-dhcp.cox.net> (at Wed, 21 Dec 2005 14:52:59 -0800), Junio C Hamano <junkio@cox.net> says:
>
> > This is the second reply to Yoshifuji-san today that did not
> > come back to me from the list (but I did get it back from my ISP
> > due to BCCing myself), so I am resending.
>
> I got all of them; with and without my Japanese name on To:.
The vger.kernel.org spam filter filters out all non-ascii character
sets. We have to do this because Matti and myself do all of the
filtering by hand, and we do not understand so many languages as to be
able to make sensible filters for spam in languages such as Japanese,
Korean, Chinese, Russian, etc. so we just filter them all.
I've asked people, such as Yoshifuji-san, on a number of occaisions if
they would mind not including Japanese characters (even if it is their
name in their FROM: field) in postings to the lists.
As long as they continue to do so, replies to their postings will be
filterd when their From: field ends up in the body of the posting. I
edit the Japanese characters out by hand when I make replies to such
postings, and that is why my responses show up.
This is a pain, but no better solutions have been suggested. Before
anyone responds: 1) making the lists subscriber-only is not an option
2) Bayesian filters are hard to integrate into our setup but we are
exploring ways to make that a reality at some point nevertheless.
^ permalink raw reply
* [OT] western cultural imperialism at vger?
From: Junio C Hamano @ 2005-12-21 23:24 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: git
In-Reply-To: <20051222.080828.28117009.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
> In article <7v3bkm3vw4.fsf@assigned-by-dhcp.cox.net> (at Wed, 21 Dec 2005 14:52:59 -0800), Junio C Hamano <junkio@cox.net> says:
>
>> This is the second reply to Yoshifuji-san today that did not
>> come back to me from the list (but I did get it back from my ISP
>> due to BCCing myself), so I am resending.
>
> I got all of them; with and without my Japanese name on To:.
Your "oops this is the corrected patch" message appeared in my
mailbox only once, which suggests vger discarded it. It does
not appear on marc nor gmane archive either.
It seems to me that vger drops messages whose content-type is
"text/plain; charset=iso-2022-jp"; this western cultural
imperialism is inexcusable -- the list accepts iso-8859-1 just
fine, so it is not like it is us-ascii only. It just does not
like iso-2022-jp.
Nah, I am just joking about the "imperialism" part, but I think
that is what is happening.
Most of your messages, although you have your Japanese name on
the From: header line, are charset=us-ascii, and indeed the body
of them are us-ascii only, and is flowing on the list just fine.
The "oops this is the corrected patch" message from you was done
as a reply to your own message, which started with something
like this (Japanese omitted for obvious reasons):
In article <20051221.192342.132228413.yoshfuji@linux-ipv6.org> (at Wed, 21 Dec 2005 19:23:42 +0900 (JST)), YOSHIFUJI Hideaki / [J][J][J][J] <yoshfuji@linux-ipv6.org> says:
> Hello.
>
> Allow address enclosed by [] in URLs, like:
> git push '[3ffe:ffff:...:1]:GIT/git'
> or
> git push 'ssh://[3ffe:ffff:...:1]/GIT/git'
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
oops, this is not correct. Please use this instead.
Which made your MUA to send it in iso-2022-jp, and I suspect
that is why I saw it only once, direct delivery.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: H. Peter Anvin @ 2005-12-21 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vpsnq3wrg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I've pushed out a v1.0.0b maint release to fix a bug in HTTP
> fetch that was discovered today X-<.
>
Wouldn't it make more sense for the maintenance release to be 1.0.1?
-hpa
^ permalink raw reply
* Re: [PATCH] GIT: Support [address] in URLs
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-12-21 23:08 UTC (permalink / raw)
To: junkio; +Cc: git, yoshfuji
In-Reply-To: <7v3bkm3vw4.fsf@assigned-by-dhcp.cox.net>
In article <7v3bkm3vw4.fsf@assigned-by-dhcp.cox.net> (at Wed, 21 Dec 2005 14:52:59 -0800), Junio C Hamano <junkio@cox.net> says:
> This is the second reply to Yoshifuji-san today that did not
> come back to me from the list (but I did get it back from my ISP
> due to BCCing myself), so I am resending.
I got all of them; with and without my Japanese name on To:.
--yoshfuji
^ permalink raw reply
* Re: [PATCH] GIT: Support [address] in URLs
From: Junio C Hamano @ 2005-12-21 23:03 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: git
In-Reply-To: <7v1x065blx.fsf@assigned-by-dhcp.cox.net>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
> But, we definitely do
> scp file1 file2 ... '[3ffe:ffff:...:1]:/tmp/'
> like
> scp file1 file2 ... remote.example.com:/tmp/
Thanks.
^ permalink raw reply
* [PATCH] Use --abbrev in git-whatchanged
From: Johannes Schindelin @ 2005-12-21 22:37 UTC (permalink / raw)
To: git, junkio
The output is much nicer on standard 80 columns. If you want the old
behaviour, you can still do
git-whatchanged --abbrev=40
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-whatchanged.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
5d0a4d9aedc8af48666744ab240cdc30b9c6cae3
diff --git a/git-whatchanged.sh b/git-whatchanged.sh
index b170f74..a30f64d 100755
--- a/git-whatchanged.sh
+++ b/git-whatchanged.sh
@@ -8,5 +8,5 @@ rev_list_args=$(git-rev-parse --sq --def
diff_tree_args=$(git-rev-parse --sq --no-revs "$@") &&
eval "git-rev-list $rev_list_args" |
-eval "git-diff-tree --stdin --pretty -r $diff_tree_args" |
+eval "git-diff-tree --stdin --pretty -r --abbrev $diff_tree_args" |
LESS="$LESS -S" ${PAGER:-less}
--
0.99.9.GIT
^ permalink raw reply related
* [ANNOUNCE] GIT 1.0.0b quickfix
From: Junio C Hamano @ 2005-12-21 22:34 UTC (permalink / raw)
To: git, linux-kernel
I've pushed out a v1.0.0b maint release to fix a bug in HTTP
fetch that was discovered today X-<.
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-21 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7vek465cev.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 21 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > If you don't use git-shell, because the same machine is used for other
> > purposes, it makes sense to introduce
> >
> > [core]
> > umask = 0002
>
> I agree the setting should not be limited to git-shell, but I do
> not think setting "umask" from git configuration is the right
> way either. For files and directories under $GIT_DIR, maybe
> imposing the policy git configuration file has is OK, but I
> think honoring the user's umask is the right thing for working
> tree files.
As we worked out in another thread, you should not have a working
directory when you write-share the repository.
So, I tend to say: use core.umask only in shared setups (in which you
should not checkout files unless you know exactly what you are doing).
Hmm? (I mean to imitate Linus here, not refer to hidden Markov models.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] GIT: Support [address] in URLs
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-12-21 22:20 UTC (permalink / raw)
To: junkio; +Cc: git, yoshfuji
In-Reply-To: <7vr7866uww.fsf@assigned-by-dhcp.cox.net>
In article <7vr7866uww.fsf@assigned-by-dhcp.cox.net> (at Wed, 21 Dec 2005 12:45:51 -0800), Junio C Hamano <junkio@cox.net> says:
> That is, how does one do something like this, with an ipv6
> literal address?
>
> telnet 127.0.0.1 80
>
> Is it done like this
>
> telnet '[::1]' 80
>
> or
> telnet '::1' 80
>
> Your patch suggests the former, but I just wanted to make sure.
In this case (telnet), we do the latter.
But, we definitely do
scp file1 file2 ... '[3ffe:ffff:...:1]:/tmp/'
like
scp file1 file2 ... remote.example.com:/tmp/
Hope this helps.
--yoshfuji
^ permalink raw reply
* Re: [PATCH] GIT: Support [address] in URLs
From: Junio C Hamano @ 2005-12-21 22:16 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: git
In-Reply-To: <20051221.192342.132228413.yoshfuji@linux-ipv6.org>
[somehow the first reply seems to have been lost]
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
> Allow address enclosed by [] in URLs, like:
> git push '[3ffe:ffff:...:1]:GIT/git'
> or
> git push 'ssh://[3ffe:ffff:...:1]/GIT/git'
I am not familiar with how things are done in ipv6 land, but I
wonder if the former is consistent with the existing practice.
That is, how does one do something like this, with an ipv6
literal address?
telnet 127.0.0.1 80
Is it done like this
telnet '[::1]' 80
or
telnet '::1' 80
Your patch suggests the former, but I just wanted to make sure.
The latter "ssh://[...]" looks like RFC 3986, and I do not have
problems with.
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-21 22:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.63.0512211502130.25834@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If you don't use git-shell, because the same machine is used for other
> purposes, it makes sense to introduce
>
> [core]
> umask = 0002
I agree the setting should not be limited to git-shell, but I do
not think setting "umask" from git configuration is the right
way either. For files and directories under $GIT_DIR, maybe
imposing the policy git configuration file has is OK, but I
think honoring the user's umask is the right thing for working
tree files.
^ permalink raw reply
* Re: [PATCH] off-by-one bugs found by valgrind
From: Pavel Roskin @ 2005-12-21 21:47 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <43A9C654.2010009@zytor.com>
On Wed, 2005-12-21 at 13:17 -0800, H. Peter Anvin wrote:
> >>quote_c_style_counted() in quote.c uses a dangerous construct, when a
> >>variable is incremented once and used twice in the same expression.
> >
> > Sorry, I do not follow you. Isn't && a sequence point?
The patch is right, but my comment was wrong, sorry.
The actual problem detected by valgrind is that sp is dereferenced
before it's checked for the upper boundary. So, if e.g. namelen is 6,
the code reads name[6] into ch and then leaves the loop.
> && is a sequence point. The code is techically fine, but it's harder
> than necessary to read.
That alone should be a good reason to apply this patch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: How to set up a shared repository
From: Johannes Schindelin @ 2005-12-21 21:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy82e5ftx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 21 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > A. Setting up the umask
> >
> > 1. Separate repository box
> >
> > If you are lucky enough that you can afford a separate machine for the
> > shared repository: Good. Just make sure that the umask is set group
> > friendly, either by ensuring that (assuming the login shell is bash)
> > $HOME/.bash_profile contains the line
> >
> > umask 0002
>
> I suspect a bash started from ssh noninteractive session does
> not read .bash_profile --- you may want to check.
Yes, you're right. But after all, this section was meant to put a little
pressure on you to agree to core.umask ;-)
> > 2. Some server accessible by ssh
> >
> > git-repo-config core.umask 0002
>
> Not yet ;-)
Well, it is a reality here ;-)
> > B. Making sure the index is not corrupted by a push
> >
> > 1. No checkout!
> >
> > You can use the shared repository just like you use CVS: no working
> > directory. To disallow a checkout, just do
> >
> > touch .git/index
> > chmod a-rwx .git/index
> >
> > Every attempt to modify the index (which is invalid), will now result in
> > an error.
>
> Arrrgh....what a hack. But it is a good hack.
It is the simplest way to achieve the goal (at least that I could think
of). Thanks for the compliment!
> > 2. Ensure index and working directory consistency (no locking)
> >
> > If you want to be able to work on the project in the shared repository,
>
> I am very tempted to end this sentence with "please don't" ;-).
You are very welcome to do so!
Of course, the use case is git itself. I host a private version with all
the goodies I like so much, and which you unfortunately do not like as
much.
It is a phantastic way to keep git up to date without having to login
manually. It is also a phantastic way to break the setup spectacularly
when something goes wrong.
> > create hooks, as follows:
>
> Your update hook looks sane if too strict. I do not think of
> any reason to push and fast forward a branch that is not pointed
> at by .git/HEAD. Not that I encourage pushing into a non-naked
> repository where an uncontrolled random development happens,
> though.
Is it too strict?
: #!/bin/sh
:
: # if the working directory contains modifications, do not allow
: # push
This checks if the ref being pushed is the current HEAD:
: HEAD=$(git-symbolic-ref HEAD)
: case "$1" in
: $HEAD)
Only if it is, this check occurs
: unset GIT_DIR
: cd .. && test -z "$(git-diff-index --name-only HEAD)";;
: esac
IMHO this does exactly the right thing: Fail only if the ref to push is
the current HEAD *and* something is not committed.
> > Note that I did not check if a push locks another push.
>
> Although it does protect against stomping on each other by
> read/do-work/re-read-and-swap cycle, push does not lock. If you
> want to run a build from the post-update hook you need to
> serialize the build yourself.
Yes, I feared that much. Also note that in my dangerous setup, something
could go awfully wrong because post-update is currently compiling git
itself, while somebody else wants to use it.
So, more and more I think about it, I should not do it then. But for a few
days, I am the only user!
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] off-by-one bugs found by valgrind
From: H. Peter Anvin @ 2005-12-21 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vr7865fq5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
>
>>Insufficient memory is allocated in index-pack.c to hold the *.idx name.
>>One more byte should be allocated to hold the terminating 0.
>
> Thanks.
>
>
>>quote_c_style_counted() in quote.c uses a dangerous construct, when a
>>variable is incremented once and used twice in the same expression.
>
> Sorry, I do not follow you. Isn't && a sequence point?
>
&& is a sequence point. The code is techically fine, but it's harder
than necessary to read.
-hpa
^ permalink raw reply
* Re: Am I doing something wrong?
From: Junio C Hamano @ 2005-12-21 21:13 UTC (permalink / raw)
To: cel, torvalds; +Cc: git
In-Reply-To: <43A9C33E.2070807@citi.umich.edu>
Chuck Lever <cel@citi.umich.edu> writes:
> maybe the Linux kernel repository needs the same treatment. i'm getting
> the "all zeros" commit error message when trying to pull from it.
Indeed.
Linus, sorry about bothering you, but could you do the same
band-aid for now and also apply the attached to your
server-info.c, please?
> Junio C Hamano wrote:
>>
>> As a band-aid, I just ran this command at the server that public
>> ones mirror from:
>>
>> $ echo >>objects/info/packs
>>
GIT 1.0.0a needs to follow soonish X-<.
-- >8 --
[PATCH] objects/info/packs: work around bug in http-fetch.c::fetch_indices()
The code to fetch pack index files in deployed clients have a
bug that causes it to ignore the pack file on the last line of
objects/info/packs file, so append an empty line to work it
around.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
server-info.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
21b1aced83195af50fd8bc9a88e7734c8ee77c0e
diff --git a/server-info.c b/server-info.c
index df19e49..6089765 100644
--- a/server-info.c
+++ b/server-info.c
@@ -200,6 +200,7 @@ static void write_pack_info_file(FILE *f
int i;
for (i = 0; i < num_pack; i++)
fprintf(fp, "P %s\n", info[i]->p->pack_name + objdirlen + 6);
+ fputc('\n', fp);
}
static int update_info_packs(int force)
--
1.0.0
^ permalink raw reply related
* Re: Am I doing something wrong?
From: Chuck Lever @ 2005-12-21 21:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvexi8bo9.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2597 bytes --]
maybe the Linux kernel repository needs the same treatment. i'm getting
the "all zeros" commit error message when trying to pull from it.
Junio C Hamano wrote:
> It turns out to be a stupid off-by-one error in http-fetch.c.
> The objects/info/packs file has the following:
>
> $ cat objects/info/packs
> P pack-46ff81b11ed16ed38caa4aada913cb08c00185b2.pack
> P pack-05f611b3b8198b262acdf678584d365f8e879aec.pack
> P pack-740c99c0be6734adbd130737dec2608dc4682761.pack
> $
>
> The code that parses this in http-fetch had an off-by-one, and
> incorrectly thought that the last entry was incomplete. This
> problem did not surface earlier, because objects/info/packs file
> used to have other information after all the P lines, but
> http-fetch was not interested in was skipping them. The latest
> update-server-info stopped producing those extra lines.
>
> As a band-aid, I just ran this command at the server that public
> ones mirror from:
>
> $ echo >>objects/info/packs
>
> The change seems to have mirrored out already, and my "broken"
> client before the attached patch successfully fetches from
> there, so hopefully things would work OK for you as well.
>
> I also have to add some code to server-info.c, to append an
> empty after objects/info/packs file to work around this bug in
> the deployed http clients.
>
> Thanks for your help in diagnosing and fixing this problem.
>
> -- >8 --
> [PATCH] http-fetch.c: fix objects/info/pack parsing.
>
> It failed to register the last pack mentioned in the
> objects/info/packs file. Also it had an independent overrun
> error.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> ---
> git diff
> diff --git a/http-fetch.c b/http-fetch.c
> index ad59f1c..3cd6ef9 100644
> --- a/http-fetch.c
> +++ b/http-fetch.c
> @@ -658,7 +658,7 @@ static int fetch_indices(struct alt_base
> switch (data[i]) {
> case 'P':
> i++;
> - if (i + 52 < buffer.posn &&
> + if (i + 52 <= buffer.posn &&
> !strncmp(data + i, " pack-", 6) &&
> !strncmp(data + i + 46, ".pack\n", 6)) {
> get_sha1_hex(data + i + 6, sha1);
> @@ -667,7 +667,7 @@ static int fetch_indices(struct alt_base
> break;
> }
> default:
> - while (data[i] != '\n')
> + while (i < buffer.posn && data[i] != '\n')
> i++;
> }
> i++;
>
> Compilation finished at Wed Dec 21 11:40:06
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] off-by-one bugs found by valgrind
From: Junio C Hamano @ 2005-12-21 20:59 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1135197348.3046.7.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> Insufficient memory is allocated in index-pack.c to hold the *.idx name.
> One more byte should be allocated to hold the terminating 0.
Thanks.
> quote_c_style_counted() in quote.c uses a dangerous construct, when a
> variable is incremented once and used twice in the same expression.
Sorry, I do not follow you. Isn't && a sequence point?
> - for (sp = name; (ch = *sp++) && (sp - name) <= namelen; ) {
> -
> + for (sp = name; sp < name + namelen; sp++) {
^ permalink raw reply
* Re: How to set up a shared repository
From: Junio C Hamano @ 2005-12-21 20:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512211919040.16640@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> A. Setting up the umask
>
> 1. Separate repository box
>
> If you are lucky enough that you can afford a separate machine for the
> shared repository: Good. Just make sure that the umask is set group
> friendly, either by ensuring that (assuming the login shell is bash)
> $HOME/.bash_profile contains the line
>
> umask 0002
I suspect a bash started from ssh noninteractive session does
not read .bash_profile --- you may want to check.
> 2. Some server accessible by ssh
>
> git-repo-config core.umask 0002
Not yet ;-)
> B. Making sure the index is not corrupted by a push
>
> 1. No checkout!
>
> You can use the shared repository just like you use CVS: no working
> directory. To disallow a checkout, just do
>
> touch .git/index
> chmod a-rwx .git/index
>
> Every attempt to modify the index (which is invalid), will now result in
> an error.
Arrrgh....what a hack. But it is a good hack.
> 2. Ensure index and working directory consistency (no locking)
>
> If you want to be able to work on the project in the shared repository,
I am very tempted to end this sentence with "please don't" ;-).
> create hooks, as follows:
Your update hook looks sane if too strict. I do not think of
any reason to push and fast forward a branch that is not pointed
at by .git/HEAD. Not that I encourage pushing into a non-naked
repository where an uncontrolled random development happens,
though.
> Note that I did not check if a push locks another push.
Although it does protect against stomping on each other by
read/do-work/re-read-and-swap cycle, push does not lock. If you
want to run a build from the post-update hook you need to
serialize the build yourself.
^ permalink raw reply
* Re: [PATCH] Avoid misleading success message on error
From: Junio C Hamano @ 2005-12-21 20:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0512211752340.16125@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When a push fails (for example when the remote head does not fast forward
> to the desired ref) it is not correct to print "Everything up-to-date".
Thanks.
^ 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