* 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
* [PATCH] off-by-one bugs found by valgrind
From: Pavel Roskin @ 2005-12-21 20:35 UTC (permalink / raw)
To: git
Insufficient memory is allocated in index-pack.c to hold the *.idx name.
One more byte should be allocated to hold the terminating 0.
quote_c_style_counted() in quote.c uses a dangerous construct, when a
variable is incremented once and used twice in the same expression.
Convert this construct to a more traditional form of the for loop.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/index-pack.c b/index-pack.c
index 785fe71..d4ce3af 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -440,7 +440,7 @@ int main(int argc, char **argv)
if (len < 5 || strcmp(pack_name + len - 5, ".pack"))
die("packfile name '%s' does not end with '.pack'",
pack_name);
- index_name_buf = xmalloc(len - 1);
+ index_name_buf = xmalloc(len);
memcpy(index_name_buf, pack_name, len - 5);
strcpy(index_name_buf + len - 5, ".idx");
index_name = index_name_buf;
diff --git a/quote.c b/quote.c
index 76eb144..00297b5 100644
--- a/quote.c
+++ b/quote.c
@@ -126,8 +126,10 @@ static int quote_c_style_counted(const c
if (!no_dq)
EMIT('"');
- for (sp = name; (ch = *sp++) && (sp - name) <= namelen; ) {
-
+ for (sp = name; sp < name + namelen; sp++) {
+ ch = *sp;
+ if (!ch)
+ break;
if ((ch < ' ') || (ch == '"') || (ch == '\\') ||
(ch == 0177)) {
needquote = 1;
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: Am I doing something wrong?
From: Junio C Hamano @ 2005-12-21 19:58 UTC (permalink / raw)
To: git; +Cc: Marcel Holtmann, Peter Baumann, Randal L. Schwartz, Luben Tuikov
In-Reply-To: <7vhd92b90w.fsf@assigned-by-dhcp.cox.net>
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
^ permalink raw reply related
* Re: Problem with the dump HTTP transport
From: Junio C Hamano @ 2005-12-21 19:14 UTC (permalink / raw)
To: Marcel Holtmann, Peter Baumann, Randal L. Schwartz; +Cc: git
In-Reply-To: <1135190585.14627.9.camel@localhost>
Marcel Holtmann <marcel@holtmann.org> writes:
> it is still not working. How long does it take on www.kernel.org to
> mirror it from the master.
Thanks for the help. I managed to reproduce it, so I can see
where it breaks.
^ permalink raw reply
* Re: Am I doing something wrong?
From: Peter Baumann @ 2005-12-21 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <802d21790512211037q4ffc5816u@mail.gmail.com>
2005/12/21, Peter Baumann <peter.baumann@gmail.com>:
> 2005/12/21, Junio C Hamano <junkio@cox.net>:
> > merlyn@stonehenge.com (Randal L. Schwartz) writes:
> >
> > >>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> > >
> > > Junio> I said I tried cloning from scratch and fetching into an old one
> > > Junio> over HTTP and succeeded, did I not? So it does not seem to be
> > > Junio> the case either.
> > >
> > > Cloning from scratch probably worked differently than starting
> > > from wherever I was.
> >
> > Yup, that's why I tried both.
> >
> > > ... However, I'm very clear on the symptoms... trying to start
> > > from wherever I had last updated, to update to the current release,
> > > failed when sucking from HTTP, but worked when sucking from GIT.
> >
> > I do not doubt you got a failure. I just couldn't reproduce it
> > easily by fetching into a copy of a stale repository. Earlier I
> > was suspecting mirroring lags (my successful trial was done
> > within the last hour) but I do not think that is the case
> > because your failure was also way after the mirroring should
> > have happened.
> >
> > Will dig a bit more when able.
> >
>
> Sorry , but I have seen this too. I deleted my git directory and
> cloned it again and it worked, but the original pull didn't work.
> (Same error as above.) I'll look if I can find a backup of my old git
> directory and look if there is the same error for you to reproduce. If
> I can find something, I'll get back to you.
>
> Peter Baumann
>
Ok. I digged a bit around and found the backup of my old git version repository.
xp:/var/tmp/git cat .git/HEAD
112d0bafd620c0e0f10614a3ba021d4de4fae331
xp:/var/tmp/git git --version
git version 0.99.9i
But I wouldn't take this for serious if I were you. If the process for
building the debian package isnt't able to set the exact version the
above is definitly not true. Can't remember what version it was :-(
xp:/var/tmp/git git pull
Fetching refs/heads/master from
http://www.kernel.org/pub/scm/git/git.git using http
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
error: Unable to find c2f3bf071ee90b01f2d629921bb04c4f798f02fa under
http://www.kernel.org/pub/scm/git/git.git/
Cannot obtain needed object c2f3bf071ee90b01f2d629921bb04c4f798f02fa
while processing commit 0000000000000000000000000000000000000000.
Peter
^ permalink raw reply
* Re: Problem with the dump HTTP transport
From: Marcel Holtmann @ 2005-12-21 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0d2baaq.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
> > Cannot obtain needed object c2f3bf071ee90b01f2d629921bb04c4f798f02fa
> > while processing commit 0000000000000000000000000000000000000000.
> > cg-fetch: objects fetch failed
> >
> > Both, git and cogito, are the latest versions from yesterday. So it
> > seems every time you repack, you need to do something extra to keep the
> > dump HTTP transport happy.
>
> The last sentence is correct and I do that (the magic word is
> git-update-server-info, and that is done as part of git-repack
> automatically), but it does not seem to apply here. It most
> likely is a mirroring delay. That c2f3... object is the commit
> at the tip of the master branch, and the repository is fully
> packed right now (except v1.0.0 tag object which is loose).
it is still not working. How long does it take on www.kernel.org to
mirror it from the master.
Regards
Marcel
^ permalink raw reply
* Re: Am I doing something wrong?
From: Peter Baumann @ 2005-12-21 18:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd92b90w.fsf@assigned-by-dhcp.cox.net>
2005/12/21, Junio C Hamano <junkio@cox.net>:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
> >>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> >
> > Junio> I said I tried cloning from scratch and fetching into an old one
> > Junio> over HTTP and succeeded, did I not? So it does not seem to be
> > Junio> the case either.
> >
> > Cloning from scratch probably worked differently than starting
> > from wherever I was.
>
> Yup, that's why I tried both.
>
> > ... However, I'm very clear on the symptoms... trying to start
> > from wherever I had last updated, to update to the current release,
> > failed when sucking from HTTP, but worked when sucking from GIT.
>
> I do not doubt you got a failure. I just couldn't reproduce it
> easily by fetching into a copy of a stale repository. Earlier I
> was suspecting mirroring lags (my successful trial was done
> within the last hour) but I do not think that is the case
> because your failure was also way after the mirroring should
> have happened.
>
> Will dig a bit more when able.
>
Sorry , but I have seen this too. I deleted my git directory and
cloned it again and it worked, but the original pull didn't work.
(Same error as above.) I'll look if I can find a backup of my old git
directory and look if there is the same error for you to reproduce. If
I can find something, I'll get back to you.
Peter Baumann
^ permalink raw reply
* How to set up a shared repository
From: Johannes Schindelin @ 2005-12-21 18:27 UTC (permalink / raw)
To: git
Hi,
I installed a shared git repository in the last few days and this is the
result. May it be useful!
Ciao,
Dscho
---
[Note: this text assumes you have applied the core.umask patch]
So, there you are. You know CVS (or at least its concepts), and you want
to set up a shared repository.
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
or by using git-shell, which you have modified by inserting
umask(0002);
at the start of main().
2. Some server accessible by ssh
If there are valid reasons not to set umask (maybe you want to allow other
uses of that machine), or if you just do not want to go through the hassle
to find out which scripts your login shell executes at startup, you just
have to
git-repo-config core.umask 0002
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.
2. Ensure index and working directory consistency (no locking)
If you want to be able to work on the project in the shared repository,
create hooks, as follows:
test -d .git/hooks || mkdir .git/hooks
cat > .git/hooks/update << EOF
#!/bin/sh
# if the working directory contains modifications, do not allow push
HEAD=$(git-symbolic-ref HEAD)
case "$1" in
$HEAD)
unset GIT_DIR
cd .. && test -z "$(git-diff-index --name-only HEAD)";;
esac
EOF
chmod a+x .git/hooks/update
cat > .git/hooks/post-update << EOF
#!/bin/sh
# checkout HEAD, and build
HEAD=$(git-symbolic-ref HEAD)
case "$1" in
$HEAD)
unset GIT_DIR
umask 0002
cd .. && git checkout -f HEAD && make;;
esac
EOF
chmod a+x .git/hooks/post-update
This assumes that your project contains a Makefile, and that the tools
necessary to build are installed on the repository server.
Note that I did not check if a push locks another push.
^ permalink raw reply
* Re: Am I doing something wrong?
From: Junio C Hamano @ 2005-12-21 18:27 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86zmmuwbzh.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> I said I tried cloning from scratch and fetching into an old one
> Junio> over HTTP and succeeded, did I not? So it does not seem to be
> Junio> the case either.
>
> Cloning from scratch probably worked differently than starting
> from wherever I was.
Yup, that's why I tried both.
> ... However, I'm very clear on the symptoms... trying to start
> from wherever I had last updated, to update to the current release,
> failed when sucking from HTTP, but worked when sucking from GIT.
I do not doubt you got a failure. I just couldn't reproduce it
easily by fetching into a copy of a stale repository. Earlier I
was suspecting mirroring lags (my successful trial was done
within the last hour) but I do not think that is the case
because your failure was also way after the mirroring should
have happened.
Will dig a bit more when able.
^ permalink raw reply
* Re: Am I doing something wrong?
From: Randal L. Schwartz @ 2005-12-21 18:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmziub9yw.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> I said I tried cloning from scratch and fetching into an old one
Junio> over HTTP and succeeded, did I not? So it does not seem to be
Junio> the case either.
Cloning from scratch probably worked differently than starting
from wherever I was.
Sorry, I didn't preserve the exact state from where I started... I
think my last update was yesterday afternoon. Would have been a good
test case. However, I'm very clear on the symptoms... trying to start
from wherever I had last updated, to update to the current release,
failed when sucking from HTTP, but worked when sucking from GIT.
In fact, I got the same exact behavior both on my Darwin laptop and my
OpenBSD box, so I had to edit them both to get away from HTTP
protocol.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Am I doing something wrong?
From: Junio C Hamano @ 2005-12-21 18:07 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <864q52xrm6.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> Sorry, I do not know what Cogito is doing there (the message is
> Junio> from an "echo" in cg-fetch). git-clone over HTTP seems to work
> Junio> for me, and I just tried git-fetch over HTTP in my random
> Junio> back-up repo that happened to be at around 0.99.9g without
> Junio> problems, so I am reasonably sure the public repository is not
> Junio> corrupt.
>
> It worked once I changed the URL from http://www to git://git
>
> Perhaps something is wrong with the archive when viewed with HTTP protocol?
I said I tried cloning from scratch and fetching into an old one
over HTTP and succeeded, did I not? So it does not seem to be
the case either.
My initial reaction after seeing the two other messages that
report failure to grab the tip of the master head was "Perhaps,
the usual mirroring delay". But considering that your failure
happened way later than when the release material was placed on
the server that public servers mirror from (which was around
01:00 US/Pacific), I do not know what to think (especially
before my caffeine ;-).
^ permalink raw reply
* Re: Problem with the dump HTTP transport
From: Junio C Hamano @ 2005-12-21 17:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1135166574.26233.64.camel@localhost>
Marcel Holtmann <marcel@holtmann.org> writes:
> Cannot obtain needed object c2f3bf071ee90b01f2d629921bb04c4f798f02fa
> while processing commit 0000000000000000000000000000000000000000.
> cg-fetch: objects fetch failed
>
> Both, git and cogito, are the latest versions from yesterday. So it
> seems every time you repack, you need to do something extra to keep the
> dump HTTP transport happy.
The last sentence is correct and I do that (the magic word is
git-update-server-info, and that is done as part of git-repack
automatically), but it does not seem to apply here. It most
likely is a mirroring delay. That c2f3... object is the commit
at the tip of the master branch, and the repository is fully
packed right now (except v1.0.0 tag object which is loose).
^ permalink raw reply
* Re: Am I doing something wrong?
From: Randal L. Schwartz @ 2005-12-21 17:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bkmcp83.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>> localhost:~/MIRROR/git-GIT % cg-fetch
>> Recovering from a previously interrupted fetch...
Junio> Sorry, I do not know what Cogito is doing there (the message is
Junio> from an "echo" in cg-fetch). git-clone over HTTP seems to work
Junio> for me, and I just tried git-fetch over HTTP in my random
Junio> back-up repo that happened to be at around 0.99.9g without
Junio> problems, so I am reasonably sure the public repository is not
Junio> corrupt.
It worked once I changed the URL from http://www to git://git
Perhaps something is wrong with the archive when viewed with HTTP protocol?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Am I doing something wrong?
From: Junio C Hamano @ 2005-12-21 17:52 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86k6dyxuke.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> localhost:~/MIRROR/git-GIT % cg-fetch
> Recovering from a previously interrupted fetch...
Sorry, I do not know what Cogito is doing there (the message is
from an "echo" in cg-fetch). git-clone over HTTP seems to work
for me, and I just tried git-fetch over HTTP in my random
back-up repo that happened to be at around 0.99.9g without
problems, so I am reasonably sure the public repository is not
corrupt.
^ permalink raw reply
* [PATCH] qgit: remove Makefile from unpack_local_scons.sh
From: Pavel Roskin @ 2005-12-21 17:10 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
unpack_local_scons.sh would install a modified version of Makefile.
However, the existing Makefile can be changed to detect and use local
scons automatically.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/Makefile b/Makefile
index 5fc9678..193153a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,11 @@
## Makefile automatically generated by unpack_local_scons.sh
-### To use scons when installed globally use
-SCONS=scons
+### Use local scons if available
+ifneq (,$(wildcard scons))
+SCONS = ./scons
+else
+SCONS = scons
+endif
### To run the local version instead, define
#SCONS=python scons.py
diff --git a/unpack_local_scons.sh b/unpack_local_scons.sh
index a1266fc..445cab2 100755
--- a/unpack_local_scons.sh
+++ b/unpack_local_scons.sh
@@ -13,46 +13,6 @@ NORMAL="\033[0m"
# if kde is there a recent tar should be too
tar xjvf scons-mini.tar.bz2
-cat > Makefile << EOF
-## Makefile automatically generated by unpack_local_scons.sh
-
-### To use scons when installed globally use
-#SCONS=scons
-### To run the local version instead, define
-SCONS=./scons
-
-# scons : compile
-# scons -c : clean
-# scons install : install
-# scons -c install : uninstall and clean
-
-# default target : use scons to build the programs
-all:
- \$(SCONS) -Q
-
-### There are several possibilities to help debugging :
-# scons --debug=explain, scons --debug=tree ..
-#
-### To optimize the runtime, use
-# scons --max-drift=1 --implicit-deps-unchanged
-debug:
- \$(SCONS) -Q --debug=tree
-
-clean:
- \$(SCONS) -c
-
-install:
- \$(SCONS) install
-
-uninstall:
- \$(SCONS) -c install
-
-## this target creates a tarball of the project
-dist:
- \$(SCONS) dist
-EOF
-
-
echo ""
echo -e $GREEN"A minimum scons distribution has been unpacked right here"
echo -e $GREEN"you can now run : "$NORMAL
--
Regards,
Pavel Roskin
^ permalink raw reply related
* getFileAnnotation: no revision
From: Pavel Roskin @ 2005-12-21 16:56 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550512210417p1d363017p9d08e3c55fc841d5@mail.gmail.com>
On Wed, 2005-12-21 at 13:17 +0100, Marco Costalba wrote:
> I cannot reproduce the bug but please Pavel, add qDebug() lines
> in git.cpp as following:
Please use a mail client that doesn't damage inline attachments, or use
attachments. The diff was wrapped before it was base64 encoded. I had
to unwrap it manually. Although, I guess you don't have much choice
with Google.
I had to replace %i with %li and (int) with (long) to make the compiler
happy. It's a 64-bit platform.
> Then, please, try to reproduce the crash and send me the output.
$ bin/qgit
Git::cancelAnnotate 0
Git::getFileHistory src/commitimpl.cpp
Git::startAnnotate 7943344
Git::runAnnotate 7943344
ASSERT getFileAnnotation: no revision
bbf2abcbcafc2e458343034c8f249ac4956ec4fb
cancelingAnnotate 0
Segmentation fault
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Avoid misleading success message on error
From: Johannes Schindelin @ 2005-12-21 16:53 UTC (permalink / raw)
To: git, junkio
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".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
send-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
67819bb187daa5a976bc3d721d5c9f920f52e4ba
diff --git a/send-pack.c b/send-pack.c
index a41bbe5..5bc2f01 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -272,7 +272,7 @@ static int send_pack(int in, int out, in
packet_flush(out);
if (new_refs)
pack_objects(out, remote_refs);
- else
+ else if (ret == 0)
fprintf(stderr, "Everything up-to-date\n");
close(out);
return ret;
--
0.99.9.GIT
^ permalink raw reply related
* Am I doing something wrong?
From: Randal L. Schwartz @ 2005-12-21 16:51 UTC (permalink / raw)
To: git
localhost:~/MIRROR/git-GIT % cg-fetch
Recovering from a previously interrupted fetch...
Fetching head...
Fetching objects...
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
error: Unable to find c2f3bf071ee90b01f2d629921bb04c4f798f02fa under http://www.kernel.org/pub/scm/git/git.git/
Cannot obtain needed object c2f3bf071ee90b01f2d629921bb04c4f798f02fa
while processing commit 0000000000000000000000000000000000000000.
cg-fetch: objects fetch failed
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Problem with the dump HTTP transport
From: Luben Tuikov @ 2005-12-21 16:26 UTC (permalink / raw)
To: Marcel Holtmann, git
In-Reply-To: <1135166574.26233.64.camel@localhost>
--- Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Junio,
>
> after you released 1.0.0, I tried to pull it over HTTP, but it fails
> with the following output:
>
> # cg-update
> Fetching head...
> Fetching objects...
> Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
> Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
> error: Unable to find c2f3bf071ee90b01f2d629921bb04c4f798f02fa under
> http://www.kernel.org/pub/scm/git/git.git/
>
> Cannot obtain needed object c2f3bf071ee90b01f2d629921bb04c4f798f02fa
> while processing commit 0000000000000000000000000000000000000000.
> cg-fetch: objects fetch failed
>
> Both, git and cogito, are the latest versions from yesterday. So it
> seems every time you repack, you need to do something extra to keep the
> dump HTTP transport happy.
I'm seeing the same thing:
$git pull
Fetching refs/heads/master from http://kernel.org/pub/scm/git/git.git using http
Getting alternates list for http://kernel.org/pub/scm/git/git.git/
Getting pack list for http://kernel.org/pub/scm/git/git.git/
error: Unable to find c2f3bf071ee90b01f2d629921bb04c4f798f02fa under
http://kernel.org/pub/scm/git/git.git/
Cannot obtain needed object c2f3bf071ee90b01f2d629921bb04c4f798f02fa
while processing commit 0000000000000000000000000000000000000000.
Luben
^ permalink raw reply
* Re: Random notes about qgit
From: Pavel Roskin @ 2005-12-21 16:22 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550512210417p1d363017p9d08e3c55fc841d5@mail.gmail.com>
On Wed, 2005-12-21 at 13:17 +0100, Marco Costalba wrote:
> On 12/21/05, Pavel Roskin <proski@gnu.org> wrote:
>
> > Thanks for making the range dialog optional, but now I don't see any way
> > to see the local changes unless I re-enable the dialog. I think it
> > should be an action activated from the menu - "diff local files to this
> > revision". Or maybe the "local" radio button in the diff pane.
> >
>
> Actually you could re-enable working dir diffs from
> menu->edit->settings->'git index'
Indeed. Thank you!
> Do you think is too hidden?
It shouldn't be an option. It should be an action, available on demand,
regardless of options. In the majority of cases, only diff to the head
revision is needed, but some users may want to see diff against other
revisions, e.g. when verifying manual merge.
Maybe there should be an option to check the local diff on startup and
indicate it somehow (not necessarily in the revision list) if it's not
empty.
But I'm not a GUI expert and I don't know how to make it easy to
discover without being constantly in the way.
> > Current qgit seems to have another crash, also annotation related. Run
> > qgit on its own repository. Select "Add range select dialog options",
> > then double click on src/commitimpl.cpp in the file list. Sometimes it
> > works, sometimes it crashes like this:
> >
> > ASSERT getFileAnnotation: no revision
> > 9771bea705024b3d0a59e1b9144adf5d77ca82d1
>
> I cannot reproduce the bug but please Pavel, add qDebug() lines
> in git.cpp as following:
OK, this will be a in separate thread.
> > "View->Revision Diff" and "View->Archive Tree" work differently. The
> > former doesn't allow to turn the pane off. I'd like it to work like
> > "View->Archive Tree". Neither can "Revision Diff" be closed from the
> > popup menu.
> >
>
> Yes, "View->Revision Diff" should be a toggle action. ;-)
OK
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-21 15:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7vlkyffcxp.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 20 Dec 2005, Junio C Hamano wrote:
> [shell]
> umask = 0002
If you don't use git-shell, because the same machine is used for other
purposes, it makes sense to introduce
[core]
umask = 0002
How about this:
---
[PATCH] Introduce core.umask
This makes it possible to setup a shared git repository by setting
[core]
umask = 0002
int the template config file.
This patch makes sure even git-init-db uses it.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
init-db.c | 21 ++++++++++++++-------
setup.c | 4 ++++
2 files changed, 18 insertions(+), 7 deletions(-)
faa7d4b101211ac1993d73bb3d02e8a6d2c40734
diff --git a/init-db.c b/init-db.c
index 41576bd..26812ce 100644
--- a/init-db.c
+++ b/init-db.c
@@ -164,6 +164,7 @@ static void create_default_files(const c
unsigned char sha1[20];
struct stat st1;
char repo_version_string[10];
+ mode_t mask, mask2;
if (len > sizeof(path)-50)
die("insane git directory %s", git_dir);
@@ -172,6 +173,19 @@ static void create_default_files(const c
if (len && path[len-1] != '/')
path[len++] = '/';
+ /* First copy the templates -- we might have the default
+ * config file there, in which case we would want to read
+ * from it after installing.
+ * The config file may contain a umask...
+ */
+ path[len] = 0;
+ umask(mask = umask(0));
+ copy_templates(path, len, template_path);
+ if (mask != (mask2 = umask(mask))) {
+ umask(mask2);
+ chmod(path, 0777 & ~mask2);
+ }
+
/*
* Create .git/refs/{heads,tags}
*/
@@ -182,13 +196,6 @@ static void create_default_files(const c
strcpy(path + len, "refs/tags");
safe_create_dir(path);
- /* First copy the templates -- we might have the default
- * config file there, in which case we would want to read
- * from it after installing.
- */
- path[len] = 0;
- copy_templates(path, len, template_path);
-
git_config(git_default_config);
/*
diff --git a/setup.c b/setup.c
index d3556ed..4e4cb46 100644
--- a/setup.c
+++ b/setup.c
@@ -180,6 +180,10 @@ int check_repository_format_version(cons
{
if (strcmp(var, "core.repositoryformatversion") == 0)
repository_format_version = git_config_int(var, value);
+
+ else if (!strcmp(var, "core.umask"))
+ umask(git_config_int(var, value));
+
return 0;
}
--
1.0.0
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 0.99.9n aka 1.0rc6
From: Olaf Hering @ 2005-12-21 12:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v7ja7rsqv.fsf@assigned-by-dhcp.cox.net>
On Wed, Dec 14, Junio C Hamano wrote:
> No more big changes from now on will be merged to the "master"
> branch, except fixes and documentation enhancements.
Can you add a 'git bisect doesnotcompile' at some point? Just marking
one commit as bad will not work, because the next offer may not compile
either.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Problem with the dump HTTP transport
From: Marcel Holtmann @ 2005-12-21 12:02 UTC (permalink / raw)
To: git
Hi Junio,
after you released 1.0.0, I tried to pull it over HTTP, but it fails
with the following output:
# cg-update
Fetching head...
Fetching objects...
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
error: Unable to find c2f3bf071ee90b01f2d629921bb04c4f798f02fa under http://www.kernel.org/pub/scm/git/git.git/
Cannot obtain needed object c2f3bf071ee90b01f2d629921bb04c4f798f02fa
while processing commit 0000000000000000000000000000000000000000.
cg-fetch: objects fetch failed
Both, git and cogito, are the latest versions from yesterday. So it
seems every time you repack, you need to do something extra to keep the
dump HTTP transport happy.
Regards
Marcel
^ permalink raw reply
* [PATCH] GIT: Support [address] in URLs
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-12-21 10:23 UTC (permalink / raw)
To: junkio; +Cc: git, yoshfuji
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>
diff --git a/connect.c b/connect.c
index 93f6f80..49f93c6 100644
--- a/connect.c
+++ b/connect.c
@@ -561,7 +561,8 @@ int git_connect(int fd[2], char *url, co
{
char command[1024];
char *host, *path = url;
- char *colon = NULL;
+ char *end;
+ int c;
int pipefd[2][2];
pid_t pid;
enum protocol protocol = PROTO_LOCAL;
@@ -571,15 +572,26 @@ int git_connect(int fd[2], char *url, co
*host = '\0';
protocol = get_protocol(url);
host += 3;
- path = strchr(host, '/');
- }
- else {
+ c = '/';
+ } else {
host = url;
- if ((colon = strchr(host, ':'))) {
- protocol = PROTO_SSH;
- *colon = '\0';
- path = colon + 1;
- }
+ c = ':';
+ }
+
+ if (host[0] == '[') {
+ end = strchr(host + 1, ']');
+ if (end) {
+ *end = 0;
+ end++;
+ host++;
+ } else
+ end = host;
+ } else
+ end = host;
+
+ if ((path = strchr(end, c)) && c == ':') {
+ protocol = PROTO_SSH;
+ *path++ = '\0';
}
if (!path || !*path)
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* [ANNOUNCE] GIT 1.0.0
From: Junio C Hamano @ 2005-12-21 8:00 UTC (permalink / raw)
To: git, linux-kernel
GIT 1.0.0 is found at the usual places:
Tarball http://www.kernel.org/pub/software/scm/git/
RPM http://www.kernel.org/pub/software/scm/git/RPMS/
Debian http://www.kernel.org/pub/software/scm/git/debian/
GIT git://git.kernel.org/pub/scm/git/git.git/
The name "1.0.0" ought to mean a significant milestone, but
actually it is not. Pre 1.0 version has been in production use
by the kernel folks for quite some time, and the changes since
1.0rc are pretty small and primarily consist of documenation
updates, clone/fetch enhancements and miscellaneous bugfixes.
Thank you all who gave patches, comments and time.
Happy hacking, and a little early ho-ho-ho.
^ 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