* Re: [PATCH 1/6] t3404 & t3411: undo copy&paste
From: Junio C Hamano @ 2009-01-27 22:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephen Haberman, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901272254450.14855@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > + sed -n "${line}p" < "$1".tmp
>> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
>> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp
>
>
> Probably. It is for debugging, anyway. As everything you only see with
> -v.
Exactly. That is why I'd rather want to see what exact insn sequence is
being fed to the "rebase -i". Because I'd be debugging my new test or
changes to "rebase -i", not debugging fake-editor's use of sed.
^ permalink raw reply
* Re: git-am annoyance
From: Johannes Schindelin @ 2009-01-27 22:49 UTC (permalink / raw)
To: sverre; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <bd6139dc0901271437l19f1201ch867f1a7c2045e54b@mail.gmail.com>
Hi,
On Tue, 27 Jan 2009, Sverre Rabbelier wrote:
> What is '-t 0'? How would one detect this in bash?
It detects if file descriptor 0 (stdin) is a terminal. "man test" to the
rescue ;-)
Ciao,
Dscho
P.S.: if I hadn't tried exactly that in my valgrind patches recently, I
would not have known either...
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Johannes Schindelin @ 2009-01-27 22:51 UTC (permalink / raw)
To: Geoffrey Lee; +Cc: git
In-Reply-To: <83d7aaa40901271441h47c98edepc16f5026de636134@mail.gmail.com>
Hi,
On Tue, 27 Jan 2009, Geoffrey Lee wrote:
> On Tue, Jan 27, 2009 at 10:24 AM, Stephen Haberman
> <stephen@exigencecorp.com> wrote:
> > It kind of works on my Vista 64-bit system--I do not see the shell
> > extensions in the native Windows Explorer (which is 64 bit), but I do
> > see the shell extensions in an Explorer replacement I use (Xplorer2)
> > that is 32-bit.
> >
> > I've seen other oddities in 32-bit vs. 64-bit programs--e.g. my alt tab
> > replacement (Joe), which is 32-bit, works great with 32-bit programs
> > but cannot remove focus from 64-bit programs (IE, Windows Explorer,
> > etc.). Ironically, very few of the programs I use are 64-bit, so I get
> > by with the alt tab replacement.
> >
> > - Stephen
> >
>
> Thanks! It seems that 64-bit explorer.exe will not load 32-bit shell
> extensions. At least now I know I'm not going crazy. :)
How could it? You cannot have 32-bit code and 64-bit code running in the
same process. At least not with x86_64 (AFAIK).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2 0/6] rebase simplifications
From: Junio C Hamano @ 2009-01-27 22:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901272323530.3586@pacific.mpi-cbg.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> Changes vs v1:
>
> removed the "rnyn" blurt (which probably marsk me as Alpine user...)
>
> removed the SHELL_PATH handling; it is a miracle to me why it works, but
> I'd rather not meddle with the magic now that you pointed it out
>
> Moved test_commit and test_merge into test-lib.sh
>
> Fixed the quoting in test_commit and test_merge
>
> AFAIR that's all...
Thanks; looks much nicer (not just relative to v1 but compared to the
original).
^ permalink raw reply
* git gui blame tooltip problem in Cygwin with multiple displays
From: Hannu Koivisto @ 2009-01-27 22:52 UTC (permalink / raw)
To: git
Hi,
I have two displays in my Windows XP SP3 machine, display 1 on the
left 1050x1680 (rotated 90deg) and display 2 (primary display) on
the right 1920x1080. Display coordinates ((top left
corner)-(bottom right corner)) are (-1050,-600)-(0,1080) and
(0,0)-(1920,1080), respectively. That is, all visible x
coordinates on display 1 are negative and y coordinates are partly
negative.
git gui blame works fine when its window is on the primary display
but if I move it to the other display, the tooltips it opens are
still opened on the primary display, far from the cursor's current
position. I wonder if the tooltip position calculations cannot
handle those negative coordinates? I found the code in question
but I can't really read tcl/tk nor have I any idea how to
instrument it to log position calculations, for example.
I realize this may be a quite rare setup and I would like to help
narrow this down but I need a debug version of the code or
something, unless of course the problem is obvious to the author or
someome who is proficient with tcl.
Tested with git 1.6.1.265.g9a013 (and some slightly older version
as well).
PS. I tried to send this, twice, directly to the list (instead of
via Gmane) and Cc the author of the code, Shawn O. Pearce, but for
some reason those mails never showed up, even though at the same
time I was able to send other mails to the list just fine. Weird.
--
Hannu
^ permalink raw reply
* Re: [PATCH 1/6] t3404 & t3411: undo copy&paste
From: Johannes Schindelin @ 2009-01-27 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Haberman, Thomas Rast, git
In-Reply-To: <7veiyo1i5y.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 27 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > + sed -n "${line}p" < "$1".tmp
> >> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
> >> > + sed -n "${line}s/^pick/$action/p" < "$1".tmp
> >
> > Probably. It is for debugging, anyway. As everything you only see with
> > -v.
>
> Exactly. That is why I'd rather want to see what exact insn sequence is
> being fed to the "rebase -i". Because I'd be debugging my new test or
> changes to "rebase -i", not debugging fake-editor's use of sed.
If you are really after seeing the constructed rebase script, then
tail -n 1 "$1"
would make tons more sense, no?
Ciao,
Dscho
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Steven Noonan @ 2009-01-27 23:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Geoffrey Lee, git
In-Reply-To: <alpine.DEB.1.00.0901272350360.3586@pacific.mpi-cbg.de>
On Tue, Jan 27, 2009 at 2:51 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 27 Jan 2009, Geoffrey Lee wrote:
>
>> On Tue, Jan 27, 2009 at 10:24 AM, Stephen Haberman
>> <stephen@exigencecorp.com> wrote:
>> > It kind of works on my Vista 64-bit system--I do not see the shell
>> > extensions in the native Windows Explorer (which is 64 bit), but I do
>> > see the shell extensions in an Explorer replacement I use (Xplorer2)
>> > that is 32-bit.
>> >
>> > I've seen other oddities in 32-bit vs. 64-bit programs--e.g. my alt tab
>> > replacement (Joe), which is 32-bit, works great with 32-bit programs
>> > but cannot remove focus from 64-bit programs (IE, Windows Explorer,
>> > etc.). Ironically, very few of the programs I use are 64-bit, so I get
>> > by with the alt tab replacement.
>> >
>> > - Stephen
>> >
>>
>> Thanks! It seems that 64-bit explorer.exe will not load 32-bit shell
>> extensions. At least now I know I'm not going crazy. :)
>
> How could it? You cannot have 32-bit code and 64-bit code running in the
> same process. At least not with x86_64 (AFAIK).
>
Correct, this is also my biggest gripe with how x86_64 is implemented.
Thank you, AMD!
- Steven
^ permalink raw reply
* Bad objects error since upgrading GitHub servers to 1.6.1
From: PJ Hyett @ 2009-01-27 23:04 UTC (permalink / raw)
To: git
Hi folks,
We upgraded our servers to Git 1.6.1 yesterday and almost immediately
starting hearing reports of "Fatal: Bad Object Error." I have
experienced this myself, so I'm 99% certain this isn't user error. I'm
also using 1.6.1 locally.
I ran into this error after trying to push code to GitHub after a
series of simple commits, I was doing absolutely nothing out of the
ordinary.
Please see our support thread for more examples:
http://support.github.com/discussions/feature-requests/157-fatal-bad-object-error-when-doing-simple-push
All of the error messages are the same. Can anyone please shed some
light on this, I don't see any other recourse but to downgrade Git
until this is resolved.
Thanks,
PJ
^ permalink raw reply
* [PATCH 0/2] Fix two issues found by valgrind
From: Johannes Schindelin @ 2009-01-27 23:07 UTC (permalink / raw)
To: git; +Cc: gitster
Okay, not tons of issues. But at least it was worth the hassle.
Johannes Schindelin (2):
test-path-utils: Fix off by one, found by valgrind
get_sha1_basic(): fix invalid memory access, found by valgrind
sha1_name.c | 2 +-
test-path-utils.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 1/2] test-path-utils: Fix off by one, found by valgrind
From: Johannes Schindelin @ 2009-01-27 23:07 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <alpine.DEB.1.00.0901280005180.3586@pacific.mpi-cbg.de>
When normalizing an absolute path, we might have to add a slash _and_ a
NUL to the buffer, so the buffer was one too small.
Let's just future proof the code and alloc PATH_MAX + 1 bytes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
test-path-utils.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/test-path-utils.c b/test-path-utils.c
index a0bcb0e..2c0f5a3 100644
--- a/test-path-utils.c
+++ b/test-path-utils.c
@@ -3,7 +3,7 @@
int main(int argc, char **argv)
{
if (argc == 3 && !strcmp(argv[1], "normalize_absolute_path")) {
- char *buf = xmalloc(strlen(argv[2])+1);
+ char *buf = xmalloc(PATH_MAX + 1);
int rv = normalize_absolute_path(buf, argv[2]);
assert(strlen(buf) == rv);
puts(buf);
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 2/2] get_sha1_basic(): fix invalid memory access, found by valgrind
From: Johannes Schindelin @ 2009-01-27 23:07 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <alpine.DEB.1.00.0901280005180.3586@pacific.mpi-cbg.de>
When get_sha1_basic() is passed a buffer of len 0, it should not
check if buf[len-1] is a curly bracket.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
sha1_name.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 7d95bbb..5d0ac02 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -334,7 +334,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
/* basic@{time or number or -number} format to query ref-log */
reflog_len = at = 0;
- if (str[len-1] == '}') {
+ if (len && str[len-1] == '}') {
for (at = len-2; at >= 0; at--) {
if (str[at] == '@' && str[at+1] == '{') {
reflog_len = (len-1) - (at+2);
--
1.6.1.482.g7d54be
^ permalink raw reply related
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: PJ Hyett @ 2009-01-27 23:10 UTC (permalink / raw)
To: git
In-Reply-To: <bab6a2ab0901271504j73dce7afjf8436c3c7c83b770@mail.gmail.com>
To expand further, here's the output from the command line when this happened.
~/Development/github(jetty)$ git push pjhyett jetty
fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
error: pack-objects died with strange error
error: failed to push some refs to 'git@github.com:pjhyett/github.git'
~/Development/github(jetty)$ git fsck --full
warning in tree 0d640d99b492b0c7db034e92d0460a7f84b22356: contains
zero-padded file modes
warning in tree 56fe2a1a3da446606aadf8861feccd592b636a34: contains
zero-padded file modes
warning in tree 99e2a89db2aa9846fc2491b3e4ccd8861e8d3283: contains
zero-padded file modes
warning in tree a6e532d7451bc4aadab86ade84df69180fab4765: contains
zero-padded file modes
dangling blob 43611213c3eff91e5fe071cf2907f69a99b630b2
dangling commit b28b3ecd85a04ecbd1dcb8aedc6886a465f6ab18
dangling commit 13a70c8687527936d2c375f0f7aefe71142de3c7
dangling commit 2aa94c1199cb332f58b70c6ce19d8de3c45c6f3c
dangling blob 61b910e7a97600691fd279e4db3662e751fb5fb7
dangling commit c4f19e16208d59666323ae0575435720be9b865d
dangling commit 19245f5d77aa449eebb4a0521b5ff4f6ce1865ab
dangling commit 122995fb7c9a7e459b0801e0647eb918bea878bf
dangling commit 7d51e3926b8720d1c7cad19aeb35d6ab4af755fd
dangling commit 1162dd21370439416967a34915832125e4975239
dangling blob 8c630b66927f6022a72e457be308de5c9ad9f4e6
dangling blob 827d4d8855fe6a3a7856ea35cd641192140f2dcd
dangling commit c9824506855d6cad9b52df115aa267d70872c2cc
dangling blob fb9bbfc3aa17c5d1ae4e15c862bd874e3476fcfc
dangling commit 46a4b39245a58ad867010f272991d6233db6288b
dangling commit d6bf5f30853fecea745559dc3a718113f3619634
dangling blob d4d66fc4c3a2cbc94d8ed9cb30a6b56daa86e58f
dangling commit b4f8d7766e8905e5ac6d6cfeeaf7370a716c24a2
Very odd that the bad object didn't appear in the fsck output.
I was able to fix the error by copying a non-corrupted version of the
object back into .git/objects and then running a git fetch.
-PJ
^ permalink raw reply
* Re: [PATCH v2 0/6] rebase simplifications
From: Johannes Schindelin @ 2009-01-27 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab9c1hyp.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 27 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > Changes vs v1:
> >
> > removed the "rnyn" blurt (which probably marsk me as Alpine user...)
> >
> > removed the SHELL_PATH handling; it is a miracle to me why it works, but
> > I'd rather not meddle with the magic now that you pointed it out
> >
> > Moved test_commit and test_merge into test-lib.sh
> >
> > Fixed the quoting in test_commit and test_merge
> >
> > AFAIR that's all...
Oh, I forgot the ${2:-...} thing...
> Thanks; looks much nicer (not just relative to v1 but compared to the
> original).
Thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Johannes Schindelin @ 2009-01-27 23:11 UTC (permalink / raw)
To: Steven Noonan; +Cc: Geoffrey Lee, git
In-Reply-To: <f488382f0901271501y2cf6dd84idc96e14aea1693e5@mail.gmail.com>
Hi,
On Tue, 27 Jan 2009, Steven Noonan wrote:
> On Tue, Jan 27, 2009 at 2:51 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Tue, 27 Jan 2009, Geoffrey Lee wrote:
> >
> >> On Tue, Jan 27, 2009 at 10:24 AM, Stephen Haberman
> >> <stephen@exigencecorp.com> wrote:
> >> > It kind of works on my Vista 64-bit system--I do not see the shell
> >> > extensions in the native Windows Explorer (which is 64 bit), but I
> >> > do see the shell extensions in an Explorer replacement I use
> >> > (Xplorer2) that is 32-bit.
> >> >
> >> > I've seen other oddities in 32-bit vs. 64-bit programs--e.g. my alt
> >> > tab replacement (Joe), which is 32-bit, works great with 32-bit
> >> > programs but cannot remove focus from 64-bit programs (IE, Windows
> >> > Explorer, etc.). Ironically, very few of the programs I use are
> >> > 64-bit, so I get by with the alt tab replacement.
> >>
> >> Thanks! It seems that 64-bit explorer.exe will not load 32-bit shell
> >> extensions. At least now I know I'm not going crazy. :)
> >
> > How could it? You cannot have 32-bit code and 64-bit code running in the
> > same process. At least not with x86_64 (AFAIK).
>
> Correct, this is also my biggest gripe with how x86_64 is implemented.
> Thank you, AMD!
Come on, at least it is not Itanium.
Ciao,
Dscho
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Steven Noonan @ 2009-01-27 23:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Geoffrey Lee, git
In-Reply-To: <alpine.DEB.1.00.0901280010530.3586@pacific.mpi-cbg.de>
On Tue, Jan 27, 2009 at 3:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 27 Jan 2009, Steven Noonan wrote:
>
>> On Tue, Jan 27, 2009 at 2:51 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >
>> > On Tue, 27 Jan 2009, Geoffrey Lee wrote:
>> >
>> >> On Tue, Jan 27, 2009 at 10:24 AM, Stephen Haberman
>> >> <stephen@exigencecorp.com> wrote:
>> >> > It kind of works on my Vista 64-bit system--I do not see the shell
>> >> > extensions in the native Windows Explorer (which is 64 bit), but I
>> >> > do see the shell extensions in an Explorer replacement I use
>> >> > (Xplorer2) that is 32-bit.
>> >> >
>> >> > I've seen other oddities in 32-bit vs. 64-bit programs--e.g. my alt
>> >> > tab replacement (Joe), which is 32-bit, works great with 32-bit
>> >> > programs but cannot remove focus from 64-bit programs (IE, Windows
>> >> > Explorer, etc.). Ironically, very few of the programs I use are
>> >> > 64-bit, so I get by with the alt tab replacement.
>> >>
>> >> Thanks! It seems that 64-bit explorer.exe will not load 32-bit shell
>> >> extensions. At least now I know I'm not going crazy. :)
>> >
>> > How could it? You cannot have 32-bit code and 64-bit code running in the
>> > same process. At least not with x86_64 (AFAIK).
>>
>> Correct, this is also my biggest gripe with how x86_64 is implemented.
>> Thank you, AMD!
>
> Come on, at least it is not Itanium.
>
True, but x86_64 had so much potential, and Itanium was doomed from the start.
http://www.emulators.com/docs/nx05_vx64.htm -- This guy has it right.
- Steven
^ permalink raw reply
* Re: [PATCH 0/2] Fix two issues found by valgrind
From: Junio C Hamano @ 2009-01-27 23:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901280005180.3586@pacific.mpi-cbg.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> Okay, not tons of issues. But at least it was worth the hassle.
Thanks.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Johannes Schindelin @ 2009-01-27 23:37 UTC (permalink / raw)
To: PJ Hyett; +Cc: git
In-Reply-To: <bab6a2ab0901271510y1e3e6912t82ff16e0f912d4b6@mail.gmail.com>
Hi,
On Tue, 27 Jan 2009, PJ Hyett wrote:
> To expand further, here's the output from the command line when this happened.
>
> ~/Development/github(jetty)$ git push pjhyett jetty
> fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
> error: pack-objects died with strange error
> error: failed to push some refs to 'git@github.com:pjhyett/github.git'
>
> ~/Development/github(jetty)$ git fsck --full
> warning in tree 0d640d99b492b0c7db034e92d0460a7f84b22356: contains
> zero-padded file modes
> warning in tree 56fe2a1a3da446606aadf8861feccd592b636a34: contains
> zero-padded file modes
> warning in tree 99e2a89db2aa9846fc2491b3e4ccd8861e8d3283: contains
> zero-padded file modes
> warning in tree a6e532d7451bc4aadab86ade84df69180fab4765: contains
> zero-padded file modes
> dangling blob 43611213c3eff91e5fe071cf2907f69a99b630b2
> dangling commit b28b3ecd85a04ecbd1dcb8aedc6886a465f6ab18
> dangling commit 13a70c8687527936d2c375f0f7aefe71142de3c7
> dangling commit 2aa94c1199cb332f58b70c6ce19d8de3c45c6f3c
> dangling blob 61b910e7a97600691fd279e4db3662e751fb5fb7
> dangling commit c4f19e16208d59666323ae0575435720be9b865d
> dangling commit 19245f5d77aa449eebb4a0521b5ff4f6ce1865ab
> dangling commit 122995fb7c9a7e459b0801e0647eb918bea878bf
> dangling commit 7d51e3926b8720d1c7cad19aeb35d6ab4af755fd
> dangling commit 1162dd21370439416967a34915832125e4975239
> dangling blob 8c630b66927f6022a72e457be308de5c9ad9f4e6
> dangling blob 827d4d8855fe6a3a7856ea35cd641192140f2dcd
> dangling commit c9824506855d6cad9b52df115aa267d70872c2cc
> dangling blob fb9bbfc3aa17c5d1ae4e15c862bd874e3476fcfc
> dangling commit 46a4b39245a58ad867010f272991d6233db6288b
> dangling commit d6bf5f30853fecea745559dc3a718113f3619634
> dangling blob d4d66fc4c3a2cbc94d8ed9cb30a6b56daa86e58f
> dangling commit b4f8d7766e8905e5ac6d6cfeeaf7370a716c24a2
>
> Very odd that the bad object didn't appear in the fsck output.
>
> I was able to fix the error by copying a non-corrupted version of the
> object back into .git/objects and then running a git fetch.
Hmm. The only thing I could think of is that the pack-objects used by
your git-daemon is somehow not at the right version...
Do you have copies of the "corrupt" objects?
Ciao,
Dscho
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Shawn O. Pearce @ 2009-01-27 23:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: PJ Hyett, git
In-Reply-To: <alpine.DEB.1.00.0901280034310.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 27 Jan 2009, PJ Hyett wrote:
>
> > To expand further, here's the output from the command line when this happened.
> >
> > ~/Development/github(jetty)$ git push pjhyett jetty
> > fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
> > error: pack-objects died with strange error
> > error: failed to push some refs to 'git@github.com:pjhyett/github.git'
>
> Hmm. The only thing I could think of is that the pack-objects used by
> your git-daemon is somehow not at the right version...
No, that's pack-objects on the client.
Its freaking weird. I don't know why a server side upgrade would
cause this on the client side.
FWIW, in 1.6.1 the only mention of those bad object messages
is inside revision.c. I can't see why we'd get one of those
by itself. I would have expected messages from deeper down
too, like from sha1_file.c.
--
Shawn.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-27 23:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, PJ Hyett, git
In-Reply-To: <20090127233939.GD1321@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Tue, 27 Jan 2009, PJ Hyett wrote:
>>
>> > To expand further, here's the output from the command line when this happened.
>> >
>> > ~/Development/github(jetty)$ git push pjhyett jetty
>> > fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
>> > error: pack-objects died with strange error
>> > error: failed to push some refs to 'git@github.com:pjhyett/github.git'
>>
>> Hmm. The only thing I could think of is that the pack-objects used by
>> your git-daemon is somehow not at the right version...
>
> No, that's pack-objects on the client.
>
> Its freaking weird. I don't know why a server side upgrade would
> cause this on the client side.
>
> FWIW, in 1.6.1 the only mention of those bad object messages
> is inside revision.c. I can't see why we'd get one of those
> by itself. I would have expected messages from deeper down
> too, like from sha1_file.c.
As we do not know what version github used to run (or for that matter what
custom code it adds to 1.6.1), I guessed that the previous one was 1.6.0.6
and did some comparison. The client side pack_object() learned to take
alternates on the server side into account to avoid pushing objects that
the target repository has through its alternates, so it is not totally
unexpected the client side changes its behaviour depending on what the
server does.
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Geoffrey Lee @ 2009-01-27 23:59 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901272350360.3586@pacific.mpi-cbg.de>
On Tue, Jan 27, 2009 at 2:51 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> How could it? You cannot have 32-bit code and 64-bit code running in the
> same process. At least not with x86_64 (AFAIK).
Yeah it seems obvious now, but I had gotten used to 64-bit Windows
being able to run 32-bit apps so seamlessly that I didn't think about
it.
-Geoffrey Lee
^ permalink raw reply
* Re: [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 0:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1233062946-22395-1-git-send-email-giuseppe.bilotta@gmail.com>
On Tue, 27 Jan 2009, Giuseppe Bilotta wrote:
> When PATH_INFO is defined, static files such as the defalt CSS or the
default
> shortcut icon are not accessible beyond the summary page (e.g. in
> shortlog or commit view).
>
> Fix this by adding a <base> tag pointing to the script base URL.
By the way, I have thought that it would conflict with use path_info
for 'blob_plain' action to have links work in document... but I forgot
that then we do not use gitweb HTML header...
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> Of course, last time I forgot that the BASE href is supposed to be
> absolute. While Opera apparently has no problem with it being relative,
> other browsers such as Firefox are stricter about it.
Errrr... I think you are talking about _full_ vs. _absolute_, not
_absolute_ vs. _relative_, see below.
>
> gitweb/gitweb.perl | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 931db4f..411b1f6 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2901,6 +2901,14 @@ sub git_header_html {
> <meta name="robots" content="index, nofollow"/>
> <title>$title</title>
> EOF
> +# the stylesheet, favicon etc urls won't work correctly with path_info unless we set the appropriate base URL
Errr... could you please break this line to not have it overly long?
> + if ($ENV{'PATH_INFO'}) {
> + my $base = $my_url;
Hmmm...
our $my_url = $cgi->url(); # = $cgi->url(-full);
our $my_uri = $cgi->url(-absolute => 1);
> + my $sname = $ENV{'SCRIPT_NAME'};
> + $base =~ s,\Q$sname\E$,,;
> + $base .= "/";
I don't think that is required; neither of $my_url and $my_uri ends
with '/' after stripping path info:
our $path_info = $ENV{"PATH_INFO"};
if ($path_info) {
$my_url =~ s,\Q$path_info\E$,,;
$my_uri =~ s,\Q$path_info\E$,,;
}
and if BASE is a document, then relative URLs are resolved using
dirname of BASE, I guess, as
http://www.w3.org/TR/html401/struct/links.html#edef-BASE
contains in example:
<BASE href="http://www.aviary.com/products/intro.html">
See also RFC1808 (Relative Uniform Resource Locators), section
4. Resolving Relative URLs:
Step 6: The last segment of the base URL's path (anything
following the rightmost slash "/", or the entire path if no
slash is present) is removed and the embedded URL's path is
appended in its place.[...]
Besides, if you strip SCRIPT_NAME, then you are left with document
root; this means that if git-logo.png etc. are in the same directory
as gitweb.cgi, they won't be found. For example for me it doesn't
work correctly (I have git-logo.png along gitweb.cgi, which is in
/cgi-bin/gitweb/... and thanks to symlinks also in /gitweb/).
By the way, according to documentation $cgi->url() should *not*
contain path_info; you have to use $cgi->url(-path_info=>1) for
that... strange.
> + print "<base href=\"$base\"/>\n";
Just in case, to be compatible with both XHML and HTML, we should use
+ print "<base href=\"$base\" />\n";
...if not for the fact that surrounding code doesn't use this way...
> + }
> # print out each stylesheet that exist
> if (defined $stylesheet) {
> #provides backwards capability for those people who define style sheet in a config file
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: PJ Hyett @ 2009-01-28 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7v1vuo1f6d.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>> On Tue, 27 Jan 2009, PJ Hyett wrote:
>>>
>>> > To expand further, here's the output from the command line when this happened.
>>> >
>>> > ~/Development/github(jetty)$ git push pjhyett jetty
>>> > fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
>>> > error: pack-objects died with strange error
>>> > error: failed to push some refs to 'git@github.com:pjhyett/github.git'
>>>
>>> Hmm. The only thing I could think of is that the pack-objects used by
>>> your git-daemon is somehow not at the right version...
>>
>> No, that's pack-objects on the client.
>>
>> Its freaking weird. I don't know why a server side upgrade would
>> cause this on the client side.
>>
>> FWIW, in 1.6.1 the only mention of those bad object messages
>> is inside revision.c. I can't see why we'd get one of those
>> by itself. I would have expected messages from deeper down
>> too, like from sha1_file.c.
>
> As we do not know what version github used to run (or for that matter what
> custom code it adds to 1.6.1), I guessed that the previous one was 1.6.0.6
> and did some comparison. The client side pack_object() learned to take
> alternates on the server side into account to avoid pushing objects that
> the target repository has through its alternates, so it is not totally
> unexpected the client side changes its behaviour depending on what the
> server does.
Our servers were upgraded from 1.5.5.1 if that helps.
-PJ
^ permalink raw reply
* Re: [PATCHv2] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 0:20 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1232973937-23875-1-git-send-email-giuseppe.bilotta@gmail.com>
On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
> It's sick that $cgi->url() has no way to print the script base url
> without path_info information (or that, if it has, it's very well
> hidden).
Actually:
http://localhost/cgi-bin/gitweb/printenv.cgi/path/info?query=a;string=b;c=c;c=a
url(-absolute=>1) = /cgi-bin/gitweb/printenv.cgi
url(-relative=>1) = /cgi-bin/gitweb/printenv.cgi
url(-full=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi
url(-path_info=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi/path/info
url(-query=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi?query=a;string=b;c=c;c=a
url(-base=>1) = http://localhost
$ENV{'SCRIPT_NAME'} = /cgi-bin/gitweb/printenv.cgi
$ENV{'PATH_INFO'} = /path/info
With CGI.pm version 3.10
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv2] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 0:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901280120.38985.jnareb@gmail.com>
On Wed, Jan 28, 2009 at 1:20 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
>
>> It's sick that $cgi->url() has no way to print the script base url
>> without path_info information (or that, if it has, it's very well
>> hidden).
>
> Actually:
>
> http://localhost/cgi-bin/gitweb/printenv.cgi/path/info?query=a;string=b;c=c;c=a
>
> url(-absolute=>1) = /cgi-bin/gitweb/printenv.cgi
> url(-relative=>1) = /cgi-bin/gitweb/printenv.cgi
> url(-full=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi
> url(-path_info=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi/path/info
> url(-query=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi?query=a;string=b;c=c;c=a
> url(-base=>1) = http://localhost
>
> $ENV{'SCRIPT_NAME'} = /cgi-bin/gitweb/printenv.cgi
> $ENV{'PATH_INFO'} = /path/info
Yeah, but all of these have the script name in it, I was looking for
one without the script name. But more about this in the other reply.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: PJ Hyett @ 2009-01-28 0:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7v1vuo1f6d.fsf@gitster.siamese.dyndns.org>
> As we do not know what version github used to run (or for that matter what
> custom code it adds to 1.6.1), I guessed that the previous one was 1.6.0.6
> and did some comparison. The client side pack_object() learned to take
> alternates on the server side into account to avoid pushing objects that
> the target repository has through its alternates, so it is not totally
> unexpected the client side changes its behaviour depending on what the
> server does.
The only custom code we've written was a patch to git-daemon to map
pjhyett/github.git to a sharded location (eg.
/repositories/1/1e/df/a0/pjhyett/github.git) instead of the default.
The new alternates code in 1.6.1 sounds like that could be the issue.
-PJ
^ 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