* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 3:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: PJ Hyett, Johannes Schindelin, git
In-Reply-To: <20090128020220.GE1321@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> PJ Hyett <pjhyett@gmail.com> wrote:
>>
>> Is there any possibility to have the server code in an upcoming
>> release account for clients running 1.6.1?
>
> I can't think off-hand of a way for the server to know what version
> the client is. There's nothing really different in the protocol
> between a 1.6.1 client and a v1.5.5-rc0~44^2 (introduction of
> include-tag) or later client.
Hmm, I am puzzled.
I do not know how 41fa7d2 (Teach git-fetch to exploit server side
automatic tag following, 2008-03-03), which is about the conversation
between fetch-pack and upload-pack, is relevant to the issue at hand,
which is about the conversation between send-pack and receive-pack.
In send-pack receive-pack protocol, the server talks first before
listening to the client, and the .have data is in this first part of the
conversation.
By the way, I think Documentation/technical/pack-protocol.txt needs to be
updated. send-pack receive-pack protocol uses C and S to mean receiver
and sender respectively. We should at least s/C/R/ that part, and
possibly add description about ".have" thing.
^ permalink raw reply
* Re: [PATCH 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sverre
In-Reply-To: <7v7i4gyvzr.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 10:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Also ensure that $dotest is cleaned up if user manages to interupt mailsplit
>> while it is processing input.
>
> I do not think this "Also ensure" part is necessary nor desirable. If
> something goes wrong, we'd like to have a way to resurrect some partial
> results from the split out result.
Hmm, git-am was already nuking $dotest if mailsplit exited non-zero,
so I kept that behavior, but also clean-up if user kills git-am while
mailsplit is running.
I still think it should nuke $dotest if user hits ctrl-c, but I agree
if mailsplit exits non-zero it should not (which would be a change
from what it does now).
> The rest looked fine. Perhaps a re-roll?
Sure.
j.
^ permalink raw reply
* Re: [PATCH 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Junio C Hamano @ 2009-01-28 3:01 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, gitster, sverre
In-Reply-To: <1233110338-16806-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Also ensure that $dotest is cleaned up if user manages to interupt mailsplit
> while it is processing input.
I do not think this "Also ensure" part is necessary nor desirable. If
something goes wrong, we'd like to have a way to resurrect some partial
results from the split out result.
The rest looked fine. Perhaps a re-roll?
^ permalink raw reply
* Re: [PATCH 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 2:53 UTC (permalink / raw)
To: git; +Cc: gitster, sverre
In-Reply-To: <1233110338-16806-1-git-send-email-jaysoffian@gmail.com>
On Tue, Jan 27, 2009 at 9:38 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> When git am is called w/o arguments, w/o a patch on stdin and the user hits
> ctrl-c, it leaves behind a partially populated $dotest directory. After this
> commit, it emits usage when called w/o arguments and w/o a patch on stdin.
>
> Also ensure that $dotest is cleaned up if user manages to interupt mailsplit
> while it is processing input.
>
> Noticed by Sverre Rabbelier
Ugh, I forgot to sign-off on this and the next patch. Should I resend
or is it okay to say:
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
j.
^ permalink raw reply
* [PATCH 2/2] git-am: minor cleanups
From: Jay Soffian @ 2009-01-28 2:38 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, gitster, sverre
In-Reply-To: <1233110338-16806-1-git-send-email-jaysoffian@gmail.com>
Update usage statement to remove a no-longer supported option, and to hide two
options (one a no-op, one internal) unless --help-all is used.
Use "test -t 0" instead of deprecated "tty -s" to detect when stdin is a
terminal. (test -t 0 is used elsewhere in git-am and in other git shell
scripts, tty -s is not.)
Use "test ..." instead of "[ ... ]" and "die <msg>" instead of "echo <msg>
>&2; exit 1" to be consistent with rest of script.
---
While fixing Sverre's issue, I noticed a few other things about git-am that
seemed worth cleaning up. These seem much to small to split into separate
patches so I included them together. Let me know if they should be split.
git-am.sh | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 36227c6..2ad229b 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -8,9 +8,8 @@ OPTIONS_SPEC="\
git am [options] [<mbox>|<Maildir>...]
git am [options] (--resolved | --skip | --abort)
--
-d,dotest= (removed -- do not use)
i,interactive run interactively
-b,binary (historical option -- no-op)
+b,binary* (historical option -- no-op)
3,3way allow fall back on 3way merging if needed
s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
@@ -24,7 +23,7 @@ resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
skip skip the current patch
abort restore the original branch and abort the patching operation.
-rebasing (internal use for git-rebase)"
+rebasing* (internal use for git-rebase)"
. git-sh-setup
prefix=$(git rev-parse --show-prefix)
@@ -204,7 +203,7 @@ then
# unreliable -- stdin could be /dev/null for example
# and the caller did not intend to feed us a patch but
# wanted to continue unattended.
- tty -s
+ test -t 0
;;
*)
false
@@ -280,10 +279,7 @@ fi
case "$resolved" in
'')
files=$(git diff-index --cached --name-only HEAD --) || exit
- if [ "$files" ]; then
- echo "Dirty index: cannot apply patches (dirty: $files)" >&2
- exit 1
- fi
+ test "$files" && die "Dirty index: cannot apply patches (dirty: $files)"
esac
if test "$(cat "$dotest/utf8")" = t
--
1.6.1.224.gb56c
^ permalink raw reply related
* [PATCH 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 2:38 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, gitster, sverre
When git am is called w/o arguments, w/o a patch on stdin and the user hits
ctrl-c, it leaves behind a partially populated $dotest directory. After this
commit, it emits usage when called w/o arguments and w/o a patch on stdin.
Also ensure that $dotest is cleaned up if user manages to interupt mailsplit
while it is processing input.
Noticed by Sverre Rabbelier
---
git-am.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b1c05c9..36227c6 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -254,10 +254,10 @@ else
done
shift
fi
- git mailsplit -d"$prec" -o"$dotest" -b -- "$@" > "$dotest/last" || {
- rm -fr "$dotest"
- exit 1
- }
+ test $# = 0 && test -t 0 && usage
+ trap 'rm -fr "$dotest"' 0
+ git mailsplit -d"$prec" -o"$dotest" -b -- "$@" > "$dotest/last" || exit 1
+ trap - 0
# -s, -u, -k, --whitespace, -3, -C and -p flags are kept
# for the resuming session after a patch failure.
--
1.6.1.224.gb56c
^ permalink raw reply related
* Re: friendlier names
From: Jakub Narebski @ 2009-01-28 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, David Abrahams, git
In-Reply-To: <7vocxsy1dd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > It is a bit of pity that "git add" was overloaded to also add new
> > contents and not only add new file (and its contents!), instead of
> > having new command "git stage" to be porcelain version of
> > "git update-index" porcelain. And perhaps "git resolved" to only
> > mark resolved entries (so e.g. "git resolved ." would not add new
> > files, nor add new contents of files which were not in conflict).
>
> I do not think so.
>
> People who are taught with various means (including "git stage" alias)
> understand that you prepare the contents you want to record in the commit
> you are about to make by updating the contents registered in the index aka
> staging area, then you do not need "git resolved".
"Who are taught". This makes for Git to be more "user selective".
Not that this matter much, as world domination is not our goal ;-)
> You resolve, you have the desired content in your work tree, and you
> register the updated contents from your work tree to the index aka staging
> area, in exactly the same way as you do when you want to include updated
> contents for any commit.
While I don't think that "git resolved" is something really needed,
the difference is with "git add ." and "git resolved ." and between
"git add *" and "git resolved *", where the latter would update only
resolved merge conflict resolutions, and would not pick up independent
changes to the files that were not in conflict.
BTW with "git add" way you have to know that "git add"-ing a file
would clear 'is in merge conflict' flags (well, will hide >0 stages...).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Shawn O. Pearce @ 2009-01-28 2:02 UTC (permalink / raw)
To: PJ Hyett; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <bab6a2ab0901271757i4602774ahef1d881b7ed58097@mail.gmail.com>
PJ Hyett <pjhyett@gmail.com> wrote:
>
> Is there any possibility to have the server code in an upcoming
> release account for clients running 1.6.1?
I can't think off-hand of a way for the server to know what version
the client is. There's nothing really different in the protocol
between a 1.6.1 client and a v1.5.5-rc0~44^2 (introduction of
include-tag) or later client.
So there's no easy way for the server to work around this possible
glitch in the client.
--
Shawn.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: PJ Hyett @ 2009-01-28 1:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7vfxj4yzjj.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 5:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The extra "we also have these" advertisement happened as a result of this
>> discussion:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/95072/focus=95256
>>
>> I think I know what is going on.
>>
>> Consider this sequence of events.
>>
>> (0) Alice creates a project and pushes to public.
>>
>> alice$ cd $HOME/existing-tarball-extract
>> alice$ git init
>> alice$ git add .
>> alice$ git push /pub/alice.git master
>>
>>
>> (1) Bob forks it.
>>
>> bob$ git clone --bare --reference /pub/alice.git /pub/bob.git
>
> I need another /pub/alice.git here, I think, but I hope I got the point
> across to people who are capable of helping us to resolve this issue.
>
>>
>> (2) Bob clones his.
>>
>> bob$ cd $HOME && git clone /pub/bob.git bob
>>
>> (3) Alice works more and pushes
>>
>> alice$ edit foo
>> alice$ git add foo
>> alice$ git commit -a -m 'more'
>> alice$ git push /pub/alice.git master
>>
>> (4) Bob works more and tries to push to his.
>>
>> bob$ cd $HOME/bob
>> bob$ edit bar
>> bob$ git add bar
>> bob$ git commit -a -m 'yet more'
>> bob$ git push /pub/bob.git master
>>
>> Now, the new server advertises the objects reachable from alice's branch
>> tips as usable cut-off points for pack-objects bob will run when sending.
>>
>> And new builtin-send-pack.c has new code that feeds "extra" refs as
>>
>> ^SHA1\n
>>
>> to the pack-objects process.
>>
>> The latest commit Alice created and pushed into her repository is one such
>> commit.
>>
>> But the problem is that Bob does *NOT* have it. His "push" will run pack
>> object telling it that objects reachable from Alice's top commit do not
>> have to be sent, which was the whole point of doing this new "we also have
>> these" advertisement, but instead of ignoring that unknown commit,
>> pack-objects would say "Huh? I do not even know that commit" and dies.
>>
>> This can and should be solved by client updates, as 1.6.1 server can work
>> with older client just fine.
>
> Here is a *wrong* fix that should work most of the time. It will
> certainly appear to fix the issue in the above reproduction recipe.
> You may want to ask your users to try this to see if it makes their
> symptom disappear.
>
> When we receive ".have" advertisement, this wrong fix checks if that
> object is available locally, and it ignores it otherwise.
>
> This won't be acceptable as the official fix. We should be doing the
> full connectivity check; in other words, not just "do we have it", but "do
> we have it *and* is it reachable from any of our own refs".
>
> connect.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git c/connect.c w/connect.c
> index 2f23ab3..8026850 100644
> --- c/connect.c
> +++ w/connect.c
> @@ -43,6 +43,9 @@ int check_ref_type(const struct ref *ref, int flags)
>
> static void add_extra_have(struct extra_have_objects *extra, unsigned char *sha1)
> {
> + if (!has_sha1_file(sha1))
> + return;
> +
> ALLOC_GROW(extra->array, extra->nr + 1, extra->alloc);
> hashcpy(&(extra->array[extra->nr][0]), sha1);
> extra->nr++;
>
Thank you for your detailed response. To answer your previous
question, all of the bug reports have been made by users running
1.6.1.
My concern is that we obviously have no control over what version of
Git our 50k+ users are running, and we will be perpetually stuck
running 1.5 on the servers to account for this issue.
Is there any possibility to have the server code in an upcoming
release account for clients running 1.6.1?
-PJ
^ permalink raw reply
* Re: Heads up: rebase -i -p will be made sane again
From: Johannes Schindelin @ 2009-01-28 1:53 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git, gitster
In-Reply-To: <20090127085418.e113ad5a.stephen@exigencecorp.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2797 bytes --]
Hi,
On Tue, 27 Jan 2009, Stephen Haberman wrote:
>
> Dscho wroteÖ
>
> > As for the design bug I want to fix: imagine this history:
> >
> > ------A
> > / /
> > / /
> > ---- B
> > \ \
> > \ \
> > C-----D-----E = HEAD
> >
> > A, C and D touch the same file, and A and D agree on the contents.
> >
> > Now, rebase -p A does the following at the moment:
> >
> > ------A-----E' = HEAD
> > / /
> > / /
> > ---- B
> >
> > In other words, C is truly forgotten, and it is pretended that D never
> > happened, either. That is exactly what test case 2 in t3410 tests for
> > [*1*].
> >
> > This is insane.
>
> Agreed.
Actually, I misread t3410 a great deal. The situation is as follows:
... UPSTREAM
\
... A - B - C -D
A is a patch the upstream does not have, B is a patch UPSTREAM has,
and "git diff C^!" (i.e. the diff of C to its first parent) is _also_
identical to a diff of a merge that is in UPSTREAM.
Basically, t3410 tests that after "git rebase -i -p UPSTREAM" and leaving
the rebase script as-is, essentially, A and D are cherry-picked on top of
UPSTREAM.
> Does this mean you're just getting rid of the code that calls "rev list
> --cherry-pick"?
Only now do I understand.
I misread the code for --cherry-pick. For merges, it adds the diff to the
first parent!
I do not know if it really is desirable to have --cherry-pick handle
merges at all; I tend to think it is not.
Unfortunately, a short blame session just points to 9c6efa36 done by a
sloppy programmer: yours truly.
So I adapted my code to find the "dropped" merges in
git-rebase--interactive, too, for now, but I guess the proper fix is
something like this:
-- snipsnap --
[PATCH] --cherry-pick: do not skip merges, ever
Currently, --cherry-pick has no problem getting a patch id for merge
commits: it calculated as the patch id of the patch between the first
parent and the merge commit.
Of course, this is bogus, as it completely misses the fact that the
merge commit has other parents, too, and therefore a single patch id
would be wrong.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
patch-ids.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/patch-ids.c b/patch-ids.c
index 3be5d31..808a7f0 100644
--- a/patch-ids.c
+++ b/patch-ids.c
@@ -6,9 +6,12 @@
static int commit_patch_id(struct commit *commit, struct diff_options *options,
unsigned char *sha1)
{
- if (commit->parents)
+ if (commit->parents) {
+ if (commit->parents->next)
+ return 0; /* merges do not have a patch id */
diff_tree_sha1(commit->parents->item->object.sha1,
commit->object.sha1, "", options);
+ }
else
diff_root_tree_sha1(commit->object.sha1, "", options);
diffcore_std(options);
^ permalink raw reply related
* Re: [PATCH] send-pack: Filter unknown commits from alternates of the remote
From: Junio C Hamano @ 2009-01-28 1:47 UTC (permalink / raw)
To: Björn Steinbrink
Cc: PJ Hyett, Shawn O. Pearce, Johannes Schindelin, Linus Torvalds,
git
In-Reply-To: <20090128013840.GA7224@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Since 40c155ff14c, receive-pack on the remote also sends refs from its
> alternates. Unfortunately, we don't filter commits that don't exist in the
> local repository from that list. This made us pass those unknown commits
> to pack-objects, causing it to fail with a "bad object" error.
Yeah, it is a step in the right direction, but is the *wrong* fix I
described in my previous message.
Our mails crossed ;-)
And I think we should have this in the place where we receive .have,
i.e. inside add_extra_have() in connect.c
^ permalink raw reply
* Re: [PATCHv4] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 1:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git
In-Reply-To: <7vocxsz19e.fsf@gitster.siamese.dyndns.org>
On Wed, 28 Jan 2009, Junio C Hamano wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
> > When PATH_INFO is defined,
I other words: when using PATH_INFO gitweb URL
> > static files such as the default CSS or the
> > shortcut icon are not accessible beyond the summary page (e.g. in
> > shortlog or commit view).
To be more exact: if static files, such as the default CSS (and also
other stylesheets, if defined), the gitweb favicon / shortcut icon,
or the gitweb logo locations (URIs) are defined using relative URL
with relative path (and default Makefile rule to generate gitweb.cgi
uses basenames like 'gitweb.css', which are relative paths) _THEN_
those static files are not accessible beyond 'summary' and projects
list view (e.g. in 'shortlog' or 'commit' view).
> >
> > Fix this by adding a <base> tag pointing to the script's own URL.
Which defines base URL for all relative links in gitweb.
/Note that this makes the document hierarchy non-portable, but I don't
think we care.../
> >
> > Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> > ---
> > gitweb/gitweb.perl | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 931db4f..55e3081 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -2901,6 +2901,11 @@ 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
+# the stylesheet, favicon, etc URLs won't work correctly with path_info,
+# unless we set the appropriate base URL
By the way, I think those comments should be indented aligned to
accompanying code, but this is issue of separate whitespace cleanup,
independent of the issue this commit tries to solve.
> > + if ($ENV{'PATH_INFO'}) {
> > + print "<base href=\"$my_url\" />\n";
> > + }
>
> Perhaps this is a stupid question, but is $my_url already safe to include
> in the output without any further quoting at this point in the codepath?
Hmmmm... to be safe we probably should use either esc_url($my_url) here
(like in git_feed subroutine).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 1:44 UTC (permalink / raw)
To: Shawn O. Pearce, Johannes Schindelin; +Cc: git, PJ Hyett
In-Reply-To: <7vk58gz04l.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The extra "we also have these" advertisement happened as a result of this
> discussion:
>
> http://thread.gmane.org/gmane.comp.version-control.git/95072/focus=95256
>
> I think I know what is going on.
>
> Consider this sequence of events.
>
> (0) Alice creates a project and pushes to public.
>
> alice$ cd $HOME/existing-tarball-extract
> alice$ git init
> alice$ git add .
> alice$ git push /pub/alice.git master
>
>
> (1) Bob forks it.
>
> bob$ git clone --bare --reference /pub/alice.git /pub/bob.git
I need another /pub/alice.git here, I think, but I hope I got the point
across to people who are capable of helping us to resolve this issue.
>
> (2) Bob clones his.
>
> bob$ cd $HOME && git clone /pub/bob.git bob
>
> (3) Alice works more and pushes
>
> alice$ edit foo
> alice$ git add foo
> alice$ git commit -a -m 'more'
> alice$ git push /pub/alice.git master
>
> (4) Bob works more and tries to push to his.
>
> bob$ cd $HOME/bob
> bob$ edit bar
> bob$ git add bar
> bob$ git commit -a -m 'yet more'
> bob$ git push /pub/bob.git master
>
> Now, the new server advertises the objects reachable from alice's branch
> tips as usable cut-off points for pack-objects bob will run when sending.
>
> And new builtin-send-pack.c has new code that feeds "extra" refs as
>
> ^SHA1\n
>
> to the pack-objects process.
>
> The latest commit Alice created and pushed into her repository is one such
> commit.
>
> But the problem is that Bob does *NOT* have it. His "push" will run pack
> object telling it that objects reachable from Alice's top commit do not
> have to be sent, which was the whole point of doing this new "we also have
> these" advertisement, but instead of ignoring that unknown commit,
> pack-objects would say "Huh? I do not even know that commit" and dies.
>
> This can and should be solved by client updates, as 1.6.1 server can work
> with older client just fine.
Here is a *wrong* fix that should work most of the time. It will
certainly appear to fix the issue in the above reproduction recipe.
You may want to ask your users to try this to see if it makes their
symptom disappear.
When we receive ".have" advertisement, this wrong fix checks if that
object is available locally, and it ignores it otherwise.
This won't be acceptable as the official fix. We should be doing the
full connectivity check; in other words, not just "do we have it", but "do
we have it *and* is it reachable from any of our own refs".
connect.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git c/connect.c w/connect.c
index 2f23ab3..8026850 100644
--- c/connect.c
+++ w/connect.c
@@ -43,6 +43,9 @@ int check_ref_type(const struct ref *ref, int flags)
static void add_extra_have(struct extra_have_objects *extra, unsigned char *sha1)
{
+ if (!has_sha1_file(sha1))
+ return;
+
ALLOC_GROW(extra->array, extra->nr + 1, extra->alloc);
hashcpy(&(extra->array[extra->nr][0]), sha1);
extra->nr++;
^ permalink raw reply related
* [PATCH] send-pack: Filter unknown commits from alternates of the remote
From: Björn Steinbrink @ 2009-01-28 1:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: PJ Hyett, Shawn O. Pearce, Johannes Schindelin, Linus Torvalds,
git
In-Reply-To: <7vk58gz04l.fsf@gitster.siamese.dyndns.org>
Since 40c155ff14c, receive-pack on the remote also sends refs from its
alternates. Unfortunately, we don't filter commits that don't exist in the
local repository from that list. This made us pass those unknown commits
to pack-objects, causing it to fail with a "bad object" error.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
builtin-send-pack.c | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index a9fdbf9..10d7016 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -52,11 +52,15 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
* parameters by writing to the pipe.
*/
for (i = 0; i < extra->nr; i++) {
- memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
- buf[0] = '^';
- buf[41] = '\n';
- if (!write_or_whine(po.in, buf, 42, "send-pack: send refs"))
- break;
+ if (!is_null_sha1(&extra->array[i][0]) &&
+ has_sha1_file(&extra->array[i][0])) {
+ memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
+ buf[0] = '^';
+ buf[41] = '\n';
+ if (!write_or_whine(po.in, buf, 42,
+ "send-pack: send refs"))
+ break;
+ }
}
while (refs) {
--
1.6.1.284.g5dc13.dirty
^ permalink raw reply related
* Re: git 1.6.1 on AIX 5.3
From: Perry Smith @ 2009-01-28 1:35 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git, Jeff King
In-Reply-To: <e2b179460901270210q69fe1e42xb801553e4e9005e9@mail.gmail.com>
On Jan 27, 2009, at 4:10 AM, Mike Ralphson wrote:
> 2009/1/26 Perry Smith <pedzsan@gmail.com>:
>> Thanks guys. I picked up coreutils version 7. I didn't
>> install them but just moved ginstall over to /usr/local/bin.
>>
>> A few other comments: I had to add in the --without-tcltk flag. I
>> don't
>> have tcl installed but the config did not autodetect that it was
>> not present.
>
> Yup, I usually build with NO_TCLTK=YesPlease in my config.mak, which
> you can see from the link Peff posted.
>
> When you said 'out of tree builds' I thought you meant using the AIX
> defaults in the Makefile without running ./configure, but it seems
> not, you meant is a clone of the tree buildable by itself or are only
> release snapshots buildable. Sorry.
Sorry... I thought "out of tree" was a universal term.
Just to be sure we are on the same page. My directory structure has a
top/src/git-1.6.1
and top/build/git.1.6.1. The src/git-1.6.1 is the tar ball. The
build/git-1.6.1 starts out
empty. I cd into it and then do: ../../src/git-1.6.1/configure
<options> After this completes,
you can do "make".
About 90% of the open source configure / autoconf code out there can
do this with.
The other 10% you can not. I like it because when things die, its
easier to grep around
the source tree and I blow away the build directory and start back
over and I know that
I'm starting fresh.
>
>
> ./configure is (deliberately) a second-class citizen in the world of
> git, and may still get you a slightly suboptimal build compared with
> the defaults on platforms such as AIX... e.g. it doesn't test for
> performance-related switches such as INTERNAL_QSORT. If you have run
> configure, there's some file you need to blow away to get back to a
> non-autoconf world... is it config.mak.autogen?
>
> Despite that, your problem with --without-tcltk falling back to wish,
> but not falling back if that isn't installed does look like something
> we should fix, as per Peff's mail.
>
>> I can't tell if make test is happy or not. The output looks like
>> its happy
>> but the exit code is 2.
>>
>> Below is my "configure" script if anyone is interested.
>>
>> #!/usr/bin/env bash
>>
>> export CONFIG_SHELL=/usr/local/bin/bash
>> export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
>> export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
>> export CC=gcc
>> echo CONFIG_SHELL set to ${CONFIG_SHELL}
>>
>> ${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
>>
>> #
>> # Note that to install you need to do:
>> # make INSTALL=ginstall install
>> # to use GNU's install program
>
> I build with SHELL_PATH={path}/bash as well. If I don't, the test
> suite exits after t0000-basic.sh with an unexpected error despite
> passing all the tests.
>
> gmake -C t/ all
> gmake[1]: Entering directory `/usr/local/src/gitbuild/t'
> rm -f -r test-results
> gmake aggregate-results-and-cleanup
> gmake[2]: Entering directory `/usr/local/src/gitbuild/t'
> *** t0000-basic.sh ***
> * passed all remaining 40 test(s)
> FATAL: Unexpected exit with code 0
> gmake[2]: *** [t0000-basic.sh] Error 1
> gmake[2]: Leaving directory `/usr/local/src/gitbuild/t'
> gmake[1]: *** [all] Error 2
> gmake[1]: Leaving directory `/usr/local/src/gitbuild/t'
> gmake: *** [test] Error 2
>
> Is that what you're seeing? There's many more test scripts than that
> 8-)
>
> With GIT_SKIP_TESTS='t3900 t3901 t5100.[12] t8005' (to omit some cases
> not handled by the version of iconv I have access to on all the AIX
> boxes I deploy to) the test suit runs to completion on AIX 5.3 for me.
Yea, part of my larger quest is to start a web site to provide AIX
builds
of open source images as installp images. I have not added iconv to the
mix yet because I fear bad interactions with GNU's and AIX's. In
theory, AIX's
commands should use AIX's library but it would not surprise me if
there are
a few AIX applications that are not built properly.
>
>
> BTW Are you running AIX's make or GNU make?
yes -- GNU's make and gcc 4.3.1
I just tried setting SHELL_PATH (and exporting it) and the make test
gets into
the second batch and then fails two tests. I assume the
GIT_SKIP_TESTS is
done:
make GIT_SKIP_TESTS=....test
I get further. But now test 10 of t0001.sh fails because test_cmp can
not be found.
Is that a GNU tool? (I didn't see it in git or coreutils.)
(I'll go searching for it...)
Thank you,
Perry
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 1:32 UTC (permalink / raw)
To: PJ Hyett; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7vvds0z1c1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> PJ Hyett <pjhyett@gmail.com> writes:
> ...
>> The new alternates code in 1.6.1 sounds like that could be the issue.
>
> It could be.
>
> With the old server, when project A has a forked project A1, and A1
> borrows (via alternates) objects from A, pushing into A1 did not look at
> refs in A's repository (this all happens on the server end).
>
> With the new server, the server side also advertises the tips of A's
> branches as commits that are fully connected, when the client side tries
> to push into A1. Older clients ignored this advertisement, so when they
> pushed into A1, because their push did not depend on what's in repository
> A on the server end, did not get affected if repository A (not A1) is
> corrupted. A new client talking to the server would be affected because
> it believes what the server says.
>
> Older client ignores this advertisement, so if you are seeing trouble
> reports from people who use older clients, then you can dismiss this
> conjecture as unrelated. But if you see the issue only from people with
> new clients, this could be just exposing a repository corruption of A (not
> A1) on the server end that people did not know about before.
The extra "we also have these" advertisement happened as a result of this
discussion:
http://thread.gmane.org/gmane.comp.version-control.git/95072/focus=95256
I think I know what is going on.
Consider this sequence of events.
(0) Alice creates a project and pushes to public.
alice$ cd $HOME/existing-tarball-extract
alice$ git init
alice$ git add .
alice$ git push /pub/alice.git master
(1) Bob forks it.
bob$ git clone --bare --reference /pub/alice.git /pub/bob.git
(2) Bob clones his.
bob$ cd $HOME && git clone /pub/bob.git bob
(3) Alice works more and pushes
alice$ edit foo
alice$ git add foo
alice$ git commit -a -m 'more'
alice$ git push /pub/alice.git master
(4) Bob works more and tries to push to his.
bob$ cd $HOME/bob
bob$ edit bar
bob$ git add bar
bob$ git commit -a -m 'yet more'
bob$ git push /pub/bob.git master
Now, the new server advertises the objects reachable from alice's branch
tips as usable cut-off points for pack-objects bob will run when sending.
And new builtin-send-pack.c has new code that feeds "extra" refs as
^SHA1\n
to the pack-objects process.
The latest commit Alice created and pushed into her repository is one such
commit.
But the problem is that Bob does *NOT* have it. His "push" will run pack
object telling it that objects reachable from Alice's top commit do not
have to be sent, which was the whole point of doing this new "we also have
these" advertisement, but instead of ignoring that unknown commit,
pack-objects would say "Huh? I do not even know that commit" and dies.
This can and should be solved by client updates, as 1.6.1 server can work
with older client just fine.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Björn Steinbrink @ 2009-01-28 1:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: PJ Hyett, git
In-Reply-To: <alpine.LFD.2.00.0901271655090.3123@localhost.localdomain>
On 2009.01.27 17:00:54 -0800, Linus Torvalds wrote:
>
>
> On Tue, 27 Jan 2009, PJ Hyett wrote:
> >
> > ~/Development/github(jetty)$ git fsck --full
> > warning in tree 0d640d99b492b0c7db034e92d0460a7f84b22356: contains zero-padded file modes
> > ..
>
> Ouch. This is unrelated to your issue, but I'm wondering what project
> contains these invalid trees, and how they were created.
>
> Zero-padded tree entries can cause "object aliases", ie two trees that
> have logically the same contents end up with different data (due to
> different amounts of padding) and thus different SHA1's. It shouldn't be
> serious per se, but it's somethign that really shouldn't happen.
>
> What project does it come from, and how did such a tree get generated?
I guess that's still from their webinterface that allows to edit file
directly, without having a clone ofthe repo. The initial(?) version used
to create such broken objects. It also got the order of entries in a
tree object wrong IIRC. Back then, Scott and myself tracked that down on
#git, to their ruby(?) stuff that creates the objects. But maybe the
breakage is back?
Björn
^ permalink raw reply
* Re: [PATCHv4] gitweb: make static files accessible with PATH_INFO
From: Junio C Hamano @ 2009-01-28 1:07 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <1233103932-6325-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> When PATH_INFO is defined, static files such as the default CSS or the
> 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's own URL.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 931db4f..55e3081 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2901,6 +2901,11 @@ 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
> + if ($ENV{'PATH_INFO'}) {
> + print "<base href=\"$my_url\" />\n";
> + }
Perhaps this is a stupid question, but is $my_url already safe to include
in the output without any further quoting at this point in the codepath?
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 1:06 UTC (permalink / raw)
To: PJ Hyett; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <bab6a2ab0901271634x7201130bx4a565bd8bea6967b@mail.gmail.com>
PJ Hyett <pjhyett@gmail.com> writes:
>> 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.
It could be.
With the old server, when project A has a forked project A1, and A1
borrows (via alternates) objects from A, pushing into A1 did not look at
refs in A's repository (this all happens on the server end).
With the new server, the server side also advertises the tips of A's
branches as commits that are fully connected, when the client side tries
to push into A1. Older clients ignored this advertisement, so when they
pushed into A1, because their push did not depend on what's in repository
A on the server end, did not get affected if repository A (not A1) is
corrupted. A new client talking to the server would be affected because
it believes what the server says.
Older client ignores this advertisement, so if you are seeing trouble
reports from people who use older clients, then you can dismiss this
conjecture as unrelated. But if you see the issue only from people with
new clients, this could be just exposing a repository corruption of A (not
A1) on the server end that people did not know about before.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Linus Torvalds @ 2009-01-28 1:00 UTC (permalink / raw)
To: PJ Hyett; +Cc: git
In-Reply-To: <bab6a2ab0901271510y1e3e6912t82ff16e0f912d4b6@mail.gmail.com>
On Tue, 27 Jan 2009, PJ Hyett wrote:
>
> ~/Development/github(jetty)$ git fsck --full
> warning in tree 0d640d99b492b0c7db034e92d0460a7f84b22356: contains zero-padded file modes
> ..
Ouch. This is unrelated to your issue, but I'm wondering what project
contains these invalid trees, and how they were created.
Zero-padded tree entries can cause "object aliases", ie two trees that
have logically the same contents end up with different data (due to
different amounts of padding) and thus different SHA1's. It shouldn't be
serious per se, but it's somethign that really shouldn't happen.
What project does it come from, and how did such a tree get generated?
Linus
^ permalink raw reply
* Re: [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 0:58 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <200901280155.26399.jnareb@gmail.com>
Jakub Narebski wrote:
> On Wed, 28 Jan 2009, Giuseppe Bilotta wrote:
> > On Wed, Jan 28, 2009 at 1:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > > On Tue, 27 Jan 2009, Giuseppe Bilotta wrote:
>
> > > > 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.
> >
> > No, I actually mean absolute vs relative in the URI sense, not in the
> > Perl/CGI sense.
> >
> > http://www.example.com/ is absolute, / is relative
>
> No, "/" is not relative, it is absolute, because it begins with '/'.
Ooops, sorry, I mistook absolute _path_ for absolute _URL_.
Nevertheless path beginning with "/" inherits only net_loc (host).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 0:55 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <cb7bb73a0901271643g7c3a8c42qff6025187ab3c081@mail.gmail.com>
On Wed, 28 Jan 2009, Giuseppe Bilotta wrote:
> On Wed, Jan 28, 2009 at 1:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Tue, 27 Jan 2009, Giuseppe Bilotta wrote:
> > > 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.
>
> No, I actually mean absolute vs relative in the URI sense, not in the
> Perl/CGI sense.
>
> http://www.example.com/ is absolute, / is relative
No, "/" is not relative, it is absolute, because it begins with '/'.
See RFC 1808 (Relative Uniform Resource Locators):
2.2. BNF for Relative URLs
[...]
URL = ( absoluteURL | relativeURL ) [ "#" fragment ]
absoluteURL = generic-RL | ( scheme ":" *( uchar | reserved ) )
generic-RL = scheme ":" relativeURL
relativeURL = net_path | abs_path | rel_path
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
(which means that CGI.pm -full is 'net_path', and -absolute is
'abs_path', and -relative is 'rel_path')
[...]
4. Resolving Relative URLs
[...]
Step 4: If the embedded URL path is preceded by a slash "/", the
path is not relative and we skip to Step 7.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCHv4] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 0:52 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
When PATH_INFO is defined, static files such as the default CSS or the
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's own URL.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..55e3081 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,11 @@ 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
+ if ($ENV{'PATH_INFO'}) {
+ print "<base href=\"$my_url\" />\n";
+ }
# 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
^ permalink raw reply related
* Re: [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 0:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <200901280114.59388.jnareb@gmail.com>
On Wed, Jan 28, 2009 at 1:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> 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.
No, I actually mean absolute vs relative in the URI sense, not in the
Perl/CGI sense.
http://www.example.com/ is absolute, / is relative
>> 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?
Ah yes, sorry.
>> + 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.[...]
Ah, good point, I had missed this part, so we can actually keep the
script name in the url. Good.
> 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/).
They won't be found only if you have gitweb.cgi as directory index. In
that case you obviously need a rewrite rule at the server level
anyway. The one I use is
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.* gitweb.cgi/$0 [L,PT]
tha means 'server static files and turn anything else into pathinfo
for gitweb.cgi'
We probably want to document that. Notice that it's an issue
regardless of this particular patch.
> 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.
I think there's a bug in CGI.pm when the script is the directory index.
>> + 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...
That's the reason why I kept it that way, yes.
--
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