* Re: Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-20 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzfmm35t.fsf@assigned-by-dhcp.cox.net>
On 3/20/06, Junio C Hamano <junkio@cox.net> wrote:
>
> Your inability to produce 404 is a different matter -- often the
> hosting server is not under your control. But that does not
> change the fact that the repository observed by your clients is
> "broken". That is why a workaround flag like I suggested may be
> needed for such a setup.
>
> This is totally untested, but maybe something like this?
>
It works for me. Just some trailing white space warning when applying.
I didn't found a way to pass '--unreliable-404' flag from git-clone,
perhaps my bad,
I have tested forcing the flag in sources.
Marco
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Randal L. Schwartz @ 2006-03-20 4:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <7v7j6qqks6.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Heh, it has a striking resemblance to the first thing I said
Junio> when Linus asked me if I want to take over git.git: "It would
Junio> be embarrassing to be the first person to have an account there
Junio> without having a single line of code in the kernel" ;-).
Junio> Well, you won't be the first (in fact it appears I wasn't
Junio> either), and it would never hurt to ask.
Wow. That would perhaps completely rule out people who have never owned
anything that can execute the x86 instruction set except in emulation. :)
--
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: [PATCH] Add missing semicolon to sed command.
From: Junio C Hamano @ 2006-03-20 2:15 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060320001808.GB20765@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> generate-cmdlist.sh is giving errors messages from sed on Mac OS
> 10.4 due to a missing semicolon.
I'll take this patch for now, but I've heard a horror story that
some other vintage of sed apparently does not like multiple
commands separated by semicolons at all, and I've been training
myself to do this kind of thing always as multi-line sed script,
like this:
sed -n '
/NAME/,/git-'"$cmd"'/H
${
x
s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
p
}' "Documentation/git-$cmd.txt"
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-20 1:55 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m3wteqj6qx.fsf@lugabout.cloos.reno.nv.us>
James Cloos <cloos@jhcloos.com> writes:
> Junio> Maybe it would be a good idea to deprecate
> Junio> clone-pack altogether, use fetch-pack -k, and implement the
> Junio> "copy upstream refs to our refs" logic in git-clone.sh. We need
> Junio> to do something like that if/when we are switching to use
> Junio> $GIT_DIR/refs/remotes/ to store tracking branches outside
> Junio> refs/heads anyway.
>
> And it looks like you've shown me the door in that wall.
I was going to write that myself, but unfortunately will be
offline for the rest of the evening -- interrupted by a surprise
visitor from India who is only visiting for a few days.
So in case you are really in a rush, and in a mood to build on
top of my WIP, here is one.
* fetch-pack.c is modified so that you can say:
git fetch-pack --all -k $1
to get the list of "git ls-remote $1" equivalent while
fetching everything from the remote.
* Change git-clone.sh to use git-fetch-pack --all -k instead of
git-clone-pack; the output from fetch-pack is munged further
by a script that implements "copy the refs to the same
location while figuring out where the HEAD is". The latter
part in my WIP is incomplete so --use-separate-remote option
probably would not work right now.
---
diff --git a/fetch-pack.c b/fetch-pack.c
index 535de10..2d0a626 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -7,8 +7,9 @@
static int keep_pack;
static int quiet;
static int verbose;
+static int fetch_all;
static const char fetch_pack_usage[] =
-"git-fetch-pack [-q] [-v] [-k] [--thin] [--exec=upload-pack] [host:]directory <refs>...";
+"git-fetch-pack [--all] [-q] [-v] [-k] [--thin] [--exec=upload-pack] [host:]directory <refs>...";
static const char *exec = "git-upload-pack";
#define COMPLETE (1U << 0)
@@ -266,8 +267,9 @@ static void filter_refs(struct ref **ref
for (prev = NULL, current = *refs; current; current = next) {
next = current->next;
if ((!memcmp(current->name, "refs/", 5) &&
- check_ref_format(current->name + 5)) ||
- !path_match(current->name, nr_match, match)) {
+ check_ref_format(current->name + 5)) ||
+ (!fetch_all &&
+ !path_match(current->name, nr_match, match))) {
if (prev == NULL)
*refs = next;
else
@@ -426,6 +428,10 @@ int main(int argc, char **argv)
use_thin_pack = 1;
continue;
}
+ if (!strcmp("--all", arg)) {
+ fetch_all = 1;
+ continue;
+ }
if (!strcmp("-v", arg)) {
verbose = 1;
continue;
diff --git a/git-clone.sh b/git-clone.sh
index 4ed861d..718029b 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -40,22 +40,74 @@ Perhaps git-update-server-info needs to
do
name=`expr "$refname" : 'refs/\(.*\)'` &&
case "$name" in
- *^*) ;;
- *)
- git-http-fetch -v -a -w "$name" "$name" "$1/" || exit 1
+ *^*) continue;;
esac
+ if test -n "$use_separate_remote" &&
+ branch_name=`expr "$name" : 'heads/\(.*\)'`
+ then
+ tname="remotes/$branch_name"
+ else
+ tname=$name
+ fi
+ git-http-fetch -v -a -w "$tname" "$name" "$1/" || exit 1
done <"$clone_tmp/refs"
rm -fr "$clone_tmp"
}
+# A Perl script to read git-fetch -k output and store the
+# remote branches.
+copy_refs='
+use File::Path qw(mkpath);
+my $refs_file = $ARGV[0];
+my $use_separate_remote = $ARGV[1];
+my $git_dir = $ARGV[2];
+
+my $branch_top = ($use_separate_remote ? "heads" : "remotes");
+my $tag_top = "tags";
+my $head = undef;
+
+sub store {
+ my ($sha1, $name, $top) = @_;
+ $name = "$git_dir/refs/$top/$name";
+ mkpath(dirname($name));
+ open O, ">", "$name";
+ print O "$sha1\n";
+ close O;
+}
+
+open FH, "<", $refs_file;
+while (<FH>) {
+ my ($sha1, $name) = /^([0-9a-f]{40}) (.*)$/;
+ if ($name eq "HEAD") {
+ $head = $sha1;
+ next;
+ }
+ if ($name =~ s/^refs\/heads\//) {
+ if (!defined $head && $name eq "master") {
+ $head = $sha1;
+ }
+ store_branch($sha1, $name, $branch_top);
+ next;
+ }
+ if ($name =~ s/^refs\/tags\//) {
+ store_tag($sha1, $name, $tag_top);
+ next;
+ }
+}
+close FH;
+'
+
+
quiet=
use_local=no
local_shared=no
no_checkout=
upload_pack=
bare=
+reference=
origin=origin
origin_override=
+use_separate_remote=
while
case "$#,$1" in
0,*) break ;;
@@ -68,7 +120,14 @@ while
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; use_local=yes ;;
*,-q|*,--quiet) quiet=-q ;;
+ *,--use-separate-remote)
+ use_separate_remote=t ;;
1,-o) usage;;
+ 1,--reference) usage ;;
+ *,--reference)
+ shift; reference="$2" ;;
+ *,--reference=*)
+ reference=`expr "$1" : '--reference=\(.*\)'` ;;
*,-o)
git-check-ref-format "$2" || {
echo >&2 "'$2' is not suitable for a branch name"
@@ -130,6 +189,26 @@ yes)
GIT_DIR="$D/.git" ;;
esac
+if -n "$reference"
+then
+ if test -d "$reference
+ then
+ if test -d "$reference/.git/objects"
+ then
+ reference="$reference/.git"
+ fi
+ reference=(cd "$reference" && pwd)
+ echo "$reference/objects" >"$GIT_DIR/objects/info/alternates"
+ (cd "$reference" && tar cf - refs) |
+ (cd "$GIT_DIR/refs &&
+ mkdir reference-tmp &&
+ cd reference-tmp &&
+ tar xf -)
+ else
+ echo >&2 "$reference: not a local directory." && usage
+ fi
+fi
+
# We do local magic only when the user tells us to.
case "$local,$use_local" in
yes,yes)
@@ -217,17 +296,22 @@ yes,yes)
;;
*)
cd "$D" && case "$upload_pack" in
- '') git-clone-pack $quiet "$repo" ;;
- *) git-clone-pack $quiet "$upload_pack" "$repo" ;;
- esac || {
+ '') git-fetch-pack -k $quiet "$repo" ;;
+ *) git-fetch-pack -k $quiet "$upload_pack" "$repo" ;;
+ esac >"$GIT_DIR/FETCH_HEAD" || {
echo >&2 "clone-pack from '$repo' failed."
exit 1
}
+ # Now figure out where the remote HEAD points at.
+ perl -e "$copy_refs" "$GIT_DIR/FETCH_HEAD" \
+ "$use_separate_remote" "$GIT_DIR"
;;
esac
;;
esac
+test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp"
+
cd "$D" || exit
if test -f "$GIT_DIR/HEAD" && test -z "$bare"
^ permalink raw reply related
* Re: efficient cloning
From: James Cloos @ 2006-03-20 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu09um3ae.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> "The same repo as this script" is a very poor way to define what
Junio> you really want.
I don't think so. Getting the same values in files like FETCH_HEAD,
ORIG_HEAD, branches/*, remotes/*, info/* et al is not obvious.
Especially, eg, all of the same Push/Pull lines.
Junio> What is "git-repack -a -d -s"?
A typo. I of course meant -a -d -l.
Junio> It might be worth adding a --reference flag to git-clone like
Junio> this patch does.
That is essentially what I tried (except only the name of the flag; I
prefer your choice). I didn't include the reference-tmp logic, but
otherwise it looks about the same.
Junio> However, this patch alone does not reduce the transferred data
Junio> during cloning any smaller if you are using the "$1" repository
Junio> over git native transport (including a local repository),
Junio> because the current clone-pack does not look at existing refs
Exactly the wall I ran into. And I really only need it for git://.
Junio> Maybe it would be a good idea to deprecate
Junio> clone-pack altogether, use fetch-pack -k, and implement the
Junio> "copy upstream refs to our refs" logic in git-clone.sh. We need
Junio> to do something like that if/when we are switching to use
Junio> $GIT_DIR/refs/remotes/ to store tracking branches outside
Junio> refs/heads anyway.
And it looks like you've shown me the door in that wall.
I'll have to read up on fetch-pack as opposed to clone-pack.
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply
* [PATCH] Add missing semicolon to sed command.
From: Shawn Pearce @ 2006-03-20 0:18 UTC (permalink / raw)
To: git
generate-cmdlist.sh is giving errors messages from sed on Mac OS
10.4 due to a missing semicolon.
---
generate-cmdlist.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
base f81e7c626f34658289594386b0273755f47912a2
last 09913c10d93adbfa61138b7ac7ae6a8a210aa29f
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 6ee85d5..76ba49c 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -42,7 +42,7 @@ EOF
while read cmd
do
sed -n "/NAME/,/git-$cmd/H;
- \$ {x; s/.*git-$cmd - \\(.*\\)/ {\"$cmd\", \"\1\"},/; p}" \
+ \$ {x; s/.*git-$cmd - \\(.*\\)/ {\"$cmd\", \"\1\"},/; p;}" \
"Documentation/git-$cmd.txt"
done
echo "};"
--
1.2.4.g41f6
^ permalink raw reply related
* [PATCH] Fix multi-paragraph list items in OPTIONS section
From: Jonas Fonseca @ 2006-03-19 23:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Asciidoc cannot handle multi-paragraph description list items without the
need for adding special control characters and reindenting all paragraphs
but the first. Workaround it in make-cg-asciidoc so that the documentation
in the script headers can use the more intuitive and readable formatting.
Affected files are cg-patch and cg-commit.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/make-cg-asciidoc | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/Documentation/make-cg-asciidoc b/Documentation/make-cg-asciidoc
index 126d4eb..c454062 100755
--- a/Documentation/make-cg-asciidoc
+++ b/Documentation/make-cg-asciidoc
@@ -112,8 +112,31 @@ $DESCRIPTION
OPTIONS
-------
-$OPTIONS
+
+--
+__END__
+
+# Only indent the first paragraph of multi-paragraph list items.
+multipara=
+echo "$OPTIONS" | while read line; do
+ case "$line" in
+ *::)
+ multipara=
+ ;;
+ "")
+ multipara=t
+ ;;
+ *)
+ [ "$multipara" ] || line=" $line"
+ esac
+
+ echo "$line"
+done
+
+cat <<__END__
+
$HELP_OPTIONS
+--
$MISC
--
Jonas Fonseca
^ permalink raw reply related
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-19 23:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550603191340u466d3551t8a95c3808eb977c1@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> Finally accessing the missing object with a browser
>
> http://digilander.libero.it/mcostalba/
> scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60
>
> gives a pre-canned (in italian) 'Sorry page not found' stuff.
>
> So I really think the site "HTTP/1.0 200 OK" response it's a fake.
> Perhaps security related to avoid sniffing (just a guess because I have
> absolutely zero competence in security related things).
I think you are just rephrasing what I said. From the HTTP
protocol perspective, you _do_ have that 8d/3a0351 thing on that
server, because you do not correctly say "No we donot have it"
using 404 response.
Your inability to produce 404 is a different matter -- often the
hosting server is not under your control. But that does not
change the fact that the repository observed by your clients is
"broken". That is why a workaround flag like I suggested may be
needed for such a setup.
This is totally untested, but maybe something like this?
---
diff --git a/http-fetch.c b/http-fetch.c
index 7de818b..d523798 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -8,6 +8,7 @@
#define RANGE_HEADER_SIZE 30
static int got_alternates = -1;
+static int unreliable_404 = 0;
static struct curl_slist *no_pragma_header;
@@ -822,12 +823,18 @@ static int fetch_object(struct alt_base
close(obj_req->local); obj_req->local = -1;
}
+
+
if (obj_req->state == ABORTED) {
ret = error("Request for %s aborted", hex);
- } else if (obj_req->curl_result != CURLE_OK &&
- obj_req->http_code != 416) {
+ } else if ((obj_req->curl_result != CURLE_OK &&
+ obj_req->http_code != 416) ||
+ (unreliable_404 &&
+ obj_req->curl_result == CURLE_OK &&
+ obj_req->zret != Z_STREAM_END)) {
if (obj_req->http_code == 404 ||
- obj_req->curl_result == CURLE_FILE_COULDNT_READ_FILE)
+ obj_req->curl_result == CURLE_FILE_COULDNT_READ_FILE ||
+ unreliable_404)
ret = -1; /* Be silent, it is probably in a pack. */
else
ret = error("%s (curl_result = %d, http_code = %ld, sha1 = %s)",
@@ -966,6 +973,8 @@ int main(int argc, char **argv)
arg++;
} else if (!strcmp(argv[arg], "--recover")) {
get_recover = 1;
+ } else if (!strcmp(argv[arg], "--unreliable-404")) {
+ unreliable_404 = 1;
}
arg++;
}
^ permalink raw reply related
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-19 23:18 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m3r74ykue7.fsf@lugabout.cloos.reno.nv.us>
James Cloos <cloos@jhcloos.com> writes:
> I presume I need to clone -s -l the local alternate, re-parent it to
> the new URL and grab anything missing, but how can I assure that it
> results in exactly the same repo as this script?
"The same repo as this script" is a very poor way to define what
you really want. What is "git-repack -a -d -s"?
Guessing what you perhaps are trying to do:
- You have /gits/linux-2.6/.git on your local disk that is a
reasonably recent copy of the upstream Linux 2.6 repository.
- You want to clone from whatever $1 is (maybe a subsystem
tree, but we cannot tell from your question) to a new
directory $2.
- Presumably you know whatever $1 is is related to Linus
repository and would want to take advantage of the fact that
it shares many objects with /gits/linux-2.6/.git
It might be worth adding a --reference flag to git-clone like
this patch does.
However, this patch alone does not reduce the transferred data
during cloning any smaller if you are using the "$1" repository
over git native transport (including a local repository),
because the current clone-pack does not look at existing refs
(it was written assuming that there is _nothing_ in the cloned
repository at the beginning). That needs a separate
enhancements. Maybe it would be a good idea to deprecate
clone-pack altogether, use fetch-pack -k, and implement the
"copy upstream refs to our refs" logic in git-clone.sh. We need
to do something like that if/when we are switching to use
$GIT_DIR/refs/remotes/ to store tracking branches outside
refs/heads anyway.
The rsync transport has been deprecated for some time, and it
does not handle alternates correctly anyway, so this patch does
not have any impact on that.
But if you are going to "$1" over http transport, this patch
would help because we stash away the existing refs obtained from
the reference repository under $GIT_DIR/refs/reference-tmp while
we run the fetch.
---
diff --git a/git-clone.sh b/git-clone.sh
index 4ed861d..73fb03c 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -56,6 +56,7 @@ upload_pack=
bare=
origin=origin
origin_override=
+reference=
while
case "$#,$1" in
0,*) break ;;
@@ -68,6 +69,11 @@ while
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; use_local=yes ;;
*,-q|*,--quiet) quiet=-q ;;
+ *,--reference=*)
+ reference=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ *,--reference)
+ case "$#" in 1) usage ;; esac
+ reference="$1" ;;
1,-o) usage;;
*,-o)
git-check-ref-format "$2" || {
@@ -130,6 +136,23 @@ yes)
GIT_DIR="$D/.git" ;;
esac
+# If given a reference we would first add that one; it has to name a
+# local repository that resembles the one being cloned.
+if test -d "$reference"
+then
+ reference=$(cd "$reference" && pwd)
+ if test -d "$reference/.git/objects"
+ then
+ reference="$reference/.git"
+ fi
+ echo "$reference/objects" >"$GIT_DIR/objects/info/alternates"
+ # Pretend we know about these heads - clone-pack does not
+ # honor them currently, but that can be rectified later.
+ mkdir "$GIT_DIR/refs/reference-tmp"
+ (cd "$reference" && tar cf - refs) |
+ (cd "$GIT_DIR/refs/reference-tmp" && tar xf -)
+fi
+
# We do local magic only when the user tells us to.
case "$local,$use_local" in
yes,yes)
@@ -229,6 +252,7 @@ yes,yes)
esac
cd "$D" || exit
+test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp"
if test -f "$GIT_DIR/HEAD" && test -z "$bare"
then
^ permalink raw reply related
* Re: [PATCH 2/3] Make tutorial-script work with current cogito
From: Petr Baudis @ 2006-03-19 22:37 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060303011157.14619.99070.stgit@dv.roinet.com>
Dear diary, on Fri, Mar 03, 2006 at 02:11:57AM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> Labels on merge conflict lines have changed. There is no "git rename",
> use cg-mv instead. In one case stack.h is not created, so copy
> stack.h~master to stack.h before fixing it.
>
> Also fix comments in script.sh to use the new labels.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Whoops, overlooked this and already fixed it on my own. Thanks anyway.
> @@ -308,6 +308,7 @@ echo "Merge with 0.4" | cg-merge && shou
> # Mishandled stack.h
> ed Makefile < $TOP/0021-bob-alice-fixup1.ed
> ed rpn.c < $TOP/0022-bob-alice-fixup2.ed
> +cp stack.h~master stack.h
> ed stack.h < $TOP/0023-bob-alice-fixup3.ed
> cg-add stack.h
Isn't it enough to just kill ~master and move ~origin there, though?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: efficient cloning
From: Shawn Pearce @ 2006-03-19 22:31 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m3r74ykue7.fsf@lugabout.cloos.reno.nv.us>
James Cloos <cloos@jhcloos.com> wrote:
> Is there a way to accomplish the effect of this script w/o having to
> download any unnecessary objects?
>
> ==================================================
> #!/bin/bash
>
> lt="/gits/linux-2.6/.git"
>
> if [ $# -ne 2 ]; then
> echo >&2 "Usage: $0 <repo> <target-dir>"
> exit 1
> fi
>
> git-clone $1 $2
> mkdir -p $2/objects/info
> {
> test -f "$lt/objects/info/alternates" &&
> cat "$lt/objects/info/alternates";
> echo "$lt/objects"
> } >"$2/objects/info/alternates"
>
> cd $2
> git-repack -a -d -s
> git-prune-packed
> ==================================================
>
> I tried to modify git-clone to add an alternates file before calling
> fetch, but that file just gets deleted.
>
> I presume I need to clone -s -l the local alternate, re-parent it to
> the new URL and grab anything missing, but how can I assure that it
> results in exactly the same repo as this script?
Exactly right. There was some discussion about this perhaps just
two weeks back and it become clear that the easiest way to clone
through a thin straw is to use `git clone -s -l' from a locally
available repository which is ``close''[*1*] to the remote you are going
to actually trying to clone from, edit .git/remotes/origin to have
the correct URL: and Pull: lines, then `git-pull origin' to bring
down whatever you don't have yet. This won't miss any objects so
it will result in the same repository as a clone would have[*2*].
Footnotes:
[*1*] Here ``close'' means probably related to the same project.
Meaning if you are cloning the Linux kernel at least start with
another kernel repository and not say the GIT repository. :-)
The more your original repository has in common with the remote you
are trying to pull from the less that will need to be downloaded.
[*2*] This isn't entirely true. During a normal clone everything
is pulled down into a single pack. Using this strategy the missing
objects that are downloaded will be loose; a git-repack after
the pull might be a good idea to pull them into a pack.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] qgit 1.1.1
From: Marco Costalba @ 2006-03-19 22:04 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git, proski
In-Reply-To: <e5bfff550603191401h2c206950w1a0e04cd50fc5370@mail.gmail.com>
On 3/19/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 3/19/06, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Marco Costalba <mcostalba@gmail.com> wrote:
> >
> > > This is a maintenance release, mainly performance tweaks and small bug
> > > fixes.
> >
> > looks good here. One small bug: when in 'patch view' mode (e.g. after
> > having double-clicked on a commit), clicking on a merge commit produces
> > an "Error - Qgit" window.
> >
>
> Put in this way it seems a very major bug! really not a small one!
>
> I cannot reproduce it. Please can you give me some more info as repository
> (linux tree?) and commit sha.
>
And please also the error message that appears in qgit window so to know
what git command failed.
Thanks
Marco
^ permalink raw reply
* Re: [ANNOUNCE] qgit 1.1.1
From: Marco Costalba @ 2006-03-19 22:01 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git, proski
In-Reply-To: <20060319214907.GA7294@elte.hu>
On 3/19/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Marco Costalba <mcostalba@gmail.com> wrote:
>
> > This is a maintenance release, mainly performance tweaks and small bug
> > fixes.
>
> looks good here. One small bug: when in 'patch view' mode (e.g. after
> having double-clicked on a commit), clicking on a merge commit produces
> an "Error - Qgit" window.
>
Put in this way it seems a very major bug! really not a small one!
I cannot reproduce it. Please can you give me some more info as repository
(linux tree?) and commit sha.
Thanks
Marco
^ permalink raw reply
* Re: [ANNOUNCE] qgit 1.1.1
From: Ingo Molnar @ 2006-03-19 21:49 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, proski
In-Reply-To: <e5bfff550603190853m2db7bb38gecc94934c4dfb89e@mail.gmail.com>
* Marco Costalba <mcostalba@gmail.com> wrote:
> This is a maintenance release, mainly performance tweaks and small bug
> fixes.
looks good here. One small bug: when in 'patch view' mode (e.g. after
having double-clicked on a commit), clicking on a merge commit produces
an "Error - Qgit" window.
Ingo
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-19 21:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060319213125.GE18185@pasky.or.cz>
On 3/19/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sun, Mar 19, 2006 at 08:47:21PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >
> > > On 3/19/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > >>
> > >> How about getting an account on kernel.org?
> > >
> > > I don't think I have the credentials to ask for ;-)
> >
> > Heh, it has a striking resemblance to the first thing I said
> > when Linus asked me if I want to take over git.git: "It would
> > be embarrassing to be the first person to have an account there
> > without having a single line of code in the kernel" ;-).
> >
> > Well, you won't be the first (in fact it appears I wasn't
> > either), and it would never hurt to ask.
>
> Yeah, I think I was there before you... ;-)
>
> --
Please could someone tell me what door I should knock at?
Thanks
Marco
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Petr Baudis @ 2006-03-19 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <20060319213125.GE18185@pasky.or.cz>
Dear diary, on Sun, Mar 19, 2006 at 10:31:25PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> Dear diary, on Sun, Mar 19, 2006 at 08:47:21PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> > Heh, it has a striking resemblance to the first thing I said
> > when Linus asked me if I want to take over git.git: "It would
> > be embarrassing to be the first person to have an account there
> > without having a single line of code in the kernel" ;-).
> >
> > Well, you won't be the first (in fact it appears I wasn't
> > either), and it would never hurt to ask.
>
> Yeah, I think I was there before you... ;-)
Silly me, on a second thought I've realized that I already had some
stuff in the kernel by then. Sorry for the noise.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-19 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <7vk6aqql9e.fsf@assigned-by-dhcp.cox.net>
On 3/19/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > http://digilander.libero.it /mcostalba/scm/qgit.git/objects/8d/ea03519e75f47d
> >
> > Git does not understand object is missing and thinks what site sends
> > _is_ the requested
> > object and then founds that is (of course) corrupted.
>
> To be fair, the site is _not_ missing anything from HTTP
> protocol perspective, because when git asks 8d/ea0351... file,
> the server responds with a regular "HTTP/1.0 200 OK" response.
> So it is _your_ repository that is corrupt -- instead of
> correctly _lacking_ the file you should have removed with
> prune-packed, it has a garbage file.
>
Currently my git repo layout is as follow
$ pwd
<local master copy>/qgit.git/.git
$ ls
branches/ description HEAD index objects/ refs/
config FETCH_HEAD hooks/ info/ ORIG_HEAD remotes/
$ ls objects
2c/ 32/ 53/ 5c/ 6a/ info/ pack/
The host copy should be the exact mirror of the local copy (I use
sitecopy to sync
host). I have also verified this directly accessing the host with ftp.
So the 8d/ea0351... file is really not existent. BTW I have run git
prune and git-prune-packed
also.
Finally accessing the missing object with a browser
http://digilander.libero.it/mcostalba/
scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60
gives a pre-canned (in italian) 'Sorry page not found' stuff.
So I really think the site "HTTP/1.0 200 OK" response it's a fake.
Perhaps security related to avoid sniffing (just a guess because I have
absolutely zero competence in security related things).
Marco
^ permalink raw reply
* Re: git-reset and clones
From: Petr Baudis @ 2006-03-19 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: paul, git list
In-Reply-To: <7v4q1x95yo.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Mar 17, 2006 at 03:10:23AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> You used to have something like this:
>
>
> o---o---o---A
> / ^ your HEAD used to point at here
> ---o---o---o
>
> and you forgot other people already have the commit chain up to
> commit A. But you rewound and did cleanups:
>
> o---o---o---A
> /
> ---o---o---o---o---o---B
> ^ your HEAD now points at here
>
> People who track your HEAD have A and your updated head B does
> not fast forward. Oops.
Just for the sake of completeness, this is a GIT-only doctrine; Cogito
is more confiding and has less strict requirements.
First, when fetching, it does not care at all whether the new head is a
fast-forward of the original one or not.
Second, when the people who are tracking you had A as their current
master head _and_ also the origin remote head (or whichever their
respective branch names are), their current master head will be updated
to B when cg-updating, as Cogito pretends it to be a fast-forward even
though it is not.
So, in the simple tracking cases, Cogito will do the right thing, if you
use cg-update.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* efficient cloning
From: James Cloos @ 2006-03-19 21:16 UTC (permalink / raw)
To: git
Is there a way to accomplish the effect of this script w/o having to
download any unnecessary objects?
==================================================
#!/bin/bash
lt="/gits/linux-2.6/.git"
if [ $# -ne 2 ]; then
echo >&2 "Usage: $0 <repo> <target-dir>"
exit 1
fi
git-clone $1 $2
mkdir -p $2/objects/info
{
test -f "$lt/objects/info/alternates" &&
cat "$lt/objects/info/alternates";
echo "$lt/objects"
} >"$2/objects/info/alternates"
cd $2
git-repack -a -d -s
git-prune-packed
==================================================
I tried to modify git-clone to add an alternates file before calling
fetch, but that file just gets deleted.
I presume I need to clone -s -l the local alternate, re-parent it to
the new URL and grab anything missing, but how can I assure that it
results in exactly the same repo as this script?
I'm often behind tiny straws, so efficiency is important.
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Petr Baudis @ 2006-03-19 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <7v7j6qqks6.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Mar 19, 2006 at 08:47:21PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > On 3/19/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> >>
> >> How about getting an account on kernel.org?
> >
> > I don't think I have the credentials to ask for ;-)
>
> Heh, it has a striking resemblance to the first thing I said
> when Linus asked me if I want to take over git.git: "It would
> be embarrassing to be the first person to have an account there
> without having a single line of code in the kernel" ;-).
>
> Well, you won't be the first (in fact it appears I wasn't
> either), and it would never hurt to ask.
Yeah, I think I was there before you... ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] ls-files: Don't require exclude files to end with a newline.
From: Petr Baudis @ 2006-03-19 21:29 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <8764mccaji.fsf@wine.dyndns.org>
Dear diary, on Sat, Mar 18, 2006 at 11:27:45AM CET, I got a letter
where Alexandre Julliard <julliard@winehq.org> said that...
> Without this patch, the last line of an exclude file is silently
> ignored if it doesn't end with a newline.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
$ echo -en "a\nb" | wc -l
1
In UNIX, a line is a string terminated by a newline, therefore the blob
past the last newline character is not really a line at all. ;-)
Perhaps a warning might be in order. Why don't you just add the trailing
newline to the file?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-19 19:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550603190604ne4364f3o6a862d25267a2dce@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 3/19/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>>
>> How about getting an account on kernel.org?
>
> I don't think I have the credentials to ask for ;-)
Heh, it has a striking resemblance to the first thing I said
when Linus asked me if I want to take over git.git: "It would
be embarrassing to be the first person to have an account there
without having a single line of code in the kernel" ;-).
Well, you won't be the first (in fact it appears I wasn't
either), and it would never hurt to ask.
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Junio C Hamano @ 2006-03-19 19:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060319191243.GB18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Actually, I'm almost inclined to suggest making Git fail violently in
> case of an ambiguous name.
I am also inclined to suggest that or alternatively making it
warn, but having been almost burned by a bug or two coming from
the complexity of implementing it, I am not so enthused to start
hacking away again on this right now myself.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-19 19:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: Paolo Ciarrocchi, git, junkio
In-Reply-To: <e5bfff550603190604ne4364f3o6a862d25267a2dce@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> http://digilander.libero.it /mcostalba/scm/qgit.git/objects/8d/ea03519e75f47d
>
> Git does not understand object is missing and thinks what site sends
> _is_ the requested
> object and then founds that is (of course) corrupted.
To be fair, the site is _not_ missing anything from HTTP
protocol perspective, because when git asks 8d/ea0351... file,
the server responds with a regular "HTTP/1.0 200 OK" response.
So it is _your_ repository that is corrupt -- instead of
correctly _lacking_ the file you should have removed with
prune-packed, it has a garbage file.
Having said that, I agree that it would be nicer if we support
such a site, in the same spirit that we already bend backwards
to support really dumb hosted http servers that do not give
directory index by using objects/info/packs and info/refs.
I think it wouldn't be too much a hassle to add logic to
http-fetch.c (perhaps with an additional "--no-404" option or
somesuch) to fall back on pack transfer upon seeing a corrupt
loose object. We do the falling back when getting 404 error to
a request for a loose object, so the new code would essentially
do the same and you might be OK.
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Linus Torvalds @ 2006-03-19 19:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andreas Ericsson, Eric Wong, Martin Langhoff, git
In-Reply-To: <20060319191243.GB18185@pasky.or.cz>
On Sun, 19 Mar 2006, Petr Baudis wrote:
>
> (i) I _think_ that it would be less of a surprise if a branch would be
> checked first.
Yeah, I guess that's true.
> Actually, I'm almost inclined to suggest making Git fail violently in
> case of an ambiguous name.
Maybe not fail, but at least warn very loudly.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox