* Re: Cloning from sites with 404 overridden
From: linux @ 2006-03-22 2:59 UTC (permalink / raw)
To: git
If someone feels ambitious, you can detect this condition automatically
by searching for a file that you know won't be there and seeing if you
get a 404 response to that.
To avoid punishing good servers, it would be nice to defer the test
until reciving the first corrupted object.
I'm not sure what the best "object that's not supposed to be there" is.
It could just be a random hash, or would a malformed object file name
be better? Any fixed name has a finite chance of being created by
someone somewhere, but generating 160-bit random numbers is a PITA on
non-freenix platforms.
(As an aside, I suspect this is all caused by Microsoft's "friendly HTML
error messages" invention.)
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Shawn Pearce @ 2006-03-22 3:12 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060322025921.1722.qmail@science.horizon.com>
'0' x 40. :-) There's some places already in the GIT source
which would have ``issues'' if they got an object with this hash.
Not sure if it is actually an entirely impossible hash or just one
that is highly improbable.
My own website has this problem and its because I'm using WordPress
to handle all URLs on the site; I haven't yet found a way to
configure WordPress to return a proper 404 when the URL can't be
mapped to something on the server. Note that 404 status codes can
in fact return pretty HTML content for the user, and many websites
do this and many browsers display that pretty HTML. But a bot can
then also recognize the status code and DTRT.
The webservers are just plain broken, mine included. I think the
best option is to delay corrupt object reporting to the end of
the download process if you get only one corrupt object and that
corrupt object was actually attainable from a pack. And in this
case its just a minor warning:
Warning: The server appears to not return proper HTTP status
codes on missing files. The files were found in one or
more packs so the download is OK, but the server administrator
should really fix their server. If you know the server
administrator you might want to prod them to do so.
But that's already been suggested and I thought someone worked up
a patch based on that idea? If not I could try to do so since my
own damn server has the problem. :-)
linux@horizon.com wrote:
> If someone feels ambitious, you can detect this condition automatically
> by searching for a file that you know won't be there and seeing if you
> get a 404 response to that.
>
> To avoid punishing good servers, it would be nice to defer the test
> until reciving the first corrupted object.
>
> I'm not sure what the best "object that's not supposed to be there" is.
> It could just be a random hash, or would a malformed object file name
> be better? Any fixed name has a finite chance of being created by
> someone somewhere, but generating 160-bit random numbers is a PITA on
> non-freenix platforms.
>
>
> (As an aside, I suspect this is all caused by Microsoft's "friendly HTML
> error messages" invention.)
--
Shawn.
^ permalink raw reply
* Re: What's in git.git
From: Randal L. Schwartz @ 2006-03-22 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86y7z3mdcz.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> I'm waiting for that CVS tree to change again. It changes every
Randal> 4-5 days.
Speaking of which, I *know* you sent me a patch to apply to incorporate the
one difference, but is there a more automatic way of cherry-picking
git-cvsimport.perl from "next" into a new topic branch of mine?
For example, I can do this:
$ git-checkout next
$ cp git-cvsimport.perl DUMMY
$ git-checkout -b my-playground
$ mv DUMMY git-cvsimport.perl
$ git-commit -a -m 'trying that other version'
But this wastes a commit. Is there any way to get an index that simply
includes the file from that other branch?
--
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] Don't use merge labels in the ed scripts
From: Pavel Roskin @ 2006-03-22 4:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060321214818.GY19263@pasky.or.cz>
Hi, Petr!
On Tue, 2006-03-21 at 22:48 +0100, Petr Baudis wrote:
> > > Well, I sincerely hope that they won't change again. ;-)
> >
> > Actually, it would be nice to never expose labels starting with
> > ".merge_file_" - cogito should provide more meaningful labels instead.
>
> we shouldn't ever expose them, though. If we do, that's a bug.
It turns out those labels were produced by "git merge". Either "git
merge" should be removed from the test, or "cg-reset" should be used
after the failure. I prefer the later since it's another test for
Cogito.
Once the mess from "git merge" is cleaned up, it turns out that the last
merge in the testsuite doesn't fail, and several final fixups are no
longer needed. I think it should be OK to remove corresponding code.
It has no Cogito commands other than cg-commit, which is already tested
elsewhere.
I'm sending you the new patch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Clean up after failed "git merge" in the tutorial script
From: Pavel Roskin @ 2006-03-22 4:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Pavel Roskin <proski@gnu.org>
Failed "git merge" in the tutorial script leaves some damage to the
working directory. Use cg-reset to clean up the mess.
This eliminates conflicts in the final merge. Adjust code accordingly,
remove unused fixup scripts.
Adjust 0017-alice-bob-fixup.ed to deal with merge conflict from cg-merge
rather than "git merge".
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.../tutorial-script/0017-alice-bob-fixup.ed | 4 ++--
.../tutorial-script/0021-bob-alice-fixup1.ed | 4 ----
.../tutorial-script/0022-bob-alice-fixup2.ed | 5 -----
.../tutorial-script/0023-bob-alice-fixup3.ed | 4 ----
Documentation/tutorial-script/script.sh | 18 ++++--------------
5 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/Documentation/tutorial-script/0017-alice-bob-fixup.ed b/Documentation/tutorial-script/0017-alice-bob-fixup.ed
index ad04eb7..1b06f4e 100644
--- a/Documentation/tutorial-script/0017-alice-bob-fixup.ed
+++ b/Documentation/tutorial-script/0017-alice-bob-fixup.ed
@@ -1,5 +1,5 @@
-/^<<<<<<< Makefile/d
+/^<<<<<<< master/d
/^=======/,/^=======/+1d
-/^>>>>>>> \.merge_file_/d
+/^>>>>>>> bob/d
w
q
diff --git a/Documentation/tutorial-script/0021-bob-alice-fixup1.ed b/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
deleted file mode 100644
index df703d5..0000000
--- a/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
+++ /dev/null
@@ -1,4 +0,0 @@
-/^<<<<<<< master/,/^=======/d
-/^>>>>>>> origin/d
-w
-q
diff --git a/Documentation/tutorial-script/0022-bob-alice-fixup2.ed b/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
deleted file mode 100644
index d8c5746..0000000
--- a/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
+++ /dev/null
@@ -1,5 +0,0 @@
-/^#include "stack\.h"/+1d
-/^#include "lexer\.h"/+1,/^#include "stack\.h"/d
-/^<<<<<<< master/-1,/^>>>>>>> origin/d
-w
-q
diff --git a/Documentation/tutorial-script/0023-bob-alice-fixup3.ed b/Documentation/tutorial-script/0023-bob-alice-fixup3.ed
deleted file mode 100644
index fea2fc7..0000000
--- a/Documentation/tutorial-script/0023-bob-alice-fixup3.ed
+++ /dev/null
@@ -1,4 +0,0 @@
-/^#endif/s;^#endif.*;#endif /* STACK_H */;
-w
-q
-
diff --git a/Documentation/tutorial-script/script.sh b/Documentation/tutorial-script/script.sh
index 0401954..f07dfc1 100755
--- a/Documentation/tutorial-script/script.sh
+++ b/Documentation/tutorial-script/script.sh
@@ -222,12 +222,13 @@ git merge "Integrate changes from Bob an
# Automatic 3-way merge fails! Have to do it step by step
+cg-reset
cg-merge bob && should_fail
# Merge fails:
#: ...
-#: <<<<<<< Makefile
+#: <<<<<<< master
#: $(CC) $(CFLAGS) $^ -lm -o $@
#: =======
#: $(CC) $(CFLAGS) $^ -o $@
@@ -235,7 +236,7 @@ cg-merge bob && should_fail
#: rpn.o: stack.h
#: stack.o: stack.h
#: lexer.o:
-#: >>>>>>> .merge_file_iNhznP
+#: >>>>>>> bob
ed Makefile < $TOP/0017-alice-bob-fixup.ed
@@ -313,18 +314,7 @@ cg-fetch
git verify-tag rpn-0.4 && should_fail
# Everything's OK, integrate the changes
-echo "Merge with 0.4" | cg-merge && should_fail
-
-# Merge conflicts in Makefile, rpn.c
-ed Makefile < $TOP/0021-bob-alice-fixup1.ed
-ed rpn.c < $TOP/0022-bob-alice-fixup2.ed
-# Resolve conflicting addition of two versions of stack.h
-rm stack.h~master
-mv stack.h~origin stack.h
-cg-add stack.h
-
-# Now commit the whole
-cg-commit -m "Merge with 0.4"
+cg-merge
# Great, we are done.
trap - exit
^ permalink raw reply related
* Re: Cloning from sites with 404 overridden
From: Linus Torvalds @ 2006-03-22 4:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: linux, git
In-Reply-To: <20060322031200.GB17954@spearce.org>
On Tue, 21 Mar 2006, Shawn Pearce wrote:
>
> '0' x 40. :-) There's some places already in the GIT source
> which would have ``issues'' if they got an object with this hash.
> Not sure if it is actually an entirely impossible hash or just one
> that is highly improbable.
The all-zeroes hash is as improbable as any other one, and finding a
"collision" (ie a "real object") with that hash is as improbable as any
other collision, ie we can (and do) depend on it beign a unique identifier
for "does not exist".
Linus
^ permalink raw reply
* git daemon and v6-only
From: Jeff Garzik @ 2006-03-22 5:04 UTC (permalink / raw)
To: Git Mailing List
Regarding the following code in daemon.c socksetup():
> #ifdef IPV6_V6ONLY
> if (ai->ai_family == AF_INET6) {
> int on = 1;
> setsockopt(sockfd, IPPROTO_IPV6, IPV6_V6ONLY,
> &on, sizeof(on));
> /* Note: error is not fatal */
> }
> #endif
On Linux this causes you to bind separately to v4 and v6 interfaces,
avoiding the default (desired) behavior of using a single socket for
both v4 and v6.
Jeff
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-22 5:07 UTC (permalink / raw)
To: git
In-Reply-To: <86hd5rma75.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> For example, I can do this:
>
> $ git-checkout next
> $ cp git-cvsimport.perl DUMMY
> $ git-checkout -b my-playground
> $ mv DUMMY git-cvsimport.perl
> $ git-commit -a -m 'trying that other version'
>
> But this wastes a commit. Is there any way to get an index that simply
> includes the file from that other branch?
$ git checkout master
$ git checkout next git-cvsimport.perl
^ permalink raw reply
* Re: What's in git.git
From: Randal L. Schwartz @ 2006-03-22 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbjawyu.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>> But this wastes a commit. Is there any way to get an index that simply
>> includes the file from that other branch?
Junio> $ git checkout master
Junio> $ git checkout next git-cvsimport.perl
Yow. How simple is *that*? Thanks.
--
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: What's in git.git
From: Junio C Hamano @ 2006-03-22 5:46 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <867j6nm47b.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
>>> But this wastes a commit. Is there any way to get an index that simply
>>> includes the file from that other branch?
>
> Junio> $ git checkout master
> Junio> $ git checkout next git-cvsimport.perl
>
> Yow. How simple is *that*? Thanks.
There is one thing you would want to be careful about.
This updates the index.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-22 6:06 UTC (permalink / raw)
To: linux@horizon.com; +Cc: git, spearce, torvalds
In-Reply-To: <20060322025921.1722.qmail@science.horizon.com>
On 21 Mar 2006 21:59:21 -0500, linux@horizon.com <linux@horizon.com> wrote:
> If someone feels ambitious, you can detect this condition automatically
> by searching for a file that you know won't be there and seeing if you
> get a 404 response to that.
>
Perhaps I am proposing a total idiocy, I don't know git-fetch
internals, but wouldn't be better to avoid trying to download a non
existing object? So to fix the problem at the origin?
I don't know if it is possible to list contents before try to download
so to avoid asking for a non existing object.
Marco
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-22 6:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550603212206k1924d352xcbdb0e5a11b88a50@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> Perhaps I am proposing a total idiocy, I don't know git-fetch
> internals, but wouldn't be better to avoid trying to download a non
> existing object? So to fix the problem at the origin?
>
> I don't know if it is possible to list contents before try to download
> so to avoid asking for a non existing object.
There is no way for the downloader to know if the upstream
repository has packed which object. What is happening is that
the commit walker asks for loose object first because it does
not know. Upon getting a "no such file" (or in the case of
misconfigured HTTP server that does not say 404, "corrupt
object"), it then checks if the object appears in the pack by
downloading the pack index. It can tell what objects are in the
packs by looking at the pack index and downloads the pack that
contains needed object.
^ permalink raw reply
* Warning: fetch updated the current branch head.
From: Junio C Hamano @ 2006-03-22 9:48 UTC (permalink / raw)
To: git
I was helping somebody who:
* had a clone of git.git repository;
* had "next" checked out a week or so ago;
* did not have any development on his own;
* tried to pull using the default .git/remotes/origin from me.
Somehow the index was out of sync before that pull but there was
no change in the working tree (i.e. just the cached stat was
different), and it refused to fast-forward the index and the
working tree, because if there _were_ real changes in the
working tree, they would have been lost by a fast-forward.
This patch will be in "next" and does two things:
* runs "git update-index --refresh" before the fast-forwarding,
to prevent stat-only difference from interfering;
* if there really is a local change in the working tree, show
the original branch head information in the message, to allow
the user to decide what to do next.
The first one would have made his working tree to fast-forward
correctly. If the fast-forward is still prevented, that means
there really was a change, and in such a case, the way to recover
would be:
* Examine "git diff $orig_head" output, to make sure there is
no local change since the last pull. If there is none, you
can run "git reset --hard" (you do not have to name "next",
because that is the branch you are already on) and you are
done.
* If there are local changes, stash them away as a patch,
"git reset --hard" and re-apply if they are precious.
I've considered rewinding the tracking branch to match
$orig_head in such a case just before "die", but that would be a
disservice to people behind a narrow pipe -- it would require
them to re-download the objects to update the branch.
I now realize that the "die" message is a bit confusing, after
writing the above recovery procedure. Especially, the new
"git-update-index --refresh" would say "foo: needs update", but
"update your working tree" does not mean "git update-index foo"
after such a failure. Maybe this phrasing is better:
die 'Cannot fast-forward your working tree.
After making sure that you saved anything precious from
$ git diff '$orig_head'
output, and run
$ git reset --hard
to recover.'
Opinions?
-- >8 --
[PATCH] git-pull: further safety while on tracking branch.
Running 'git pull' while on the tracking branch has a built-in
safety valve to fast-forward the index and working tree to match
the branch head, but it errs on the safe side too cautiously.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-pull.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
cf46e7b8999f25d5d7f2acd64701a100e403ee03
diff --git a/git-pull.sh b/git-pull.sh
index 29c14e1..d90f7c9 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -55,7 +55,9 @@ then
# First update the working tree to match $curr_head.
echo >&2 "Warning: fetch updated the current branch head."
- echo >&2 "Warning: fast forwarding your working tree."
+ echo >&2 "Warning: fast forwarding your working tree from"
+ echo >&2 "Warning: $orig_head commit."
+ git-update-index --refresh 2>/dev/null
git-read-tree -u -m "$orig_head" "$curr_head" ||
die "You need to first update your working tree."
fi
--
1.2.4.gfd45
^ permalink raw reply related
* [PATCH] Format tweaks for asciidoc.
From: Francis Daly @ 2006-03-22 9:53 UTC (permalink / raw)
To: git
Some documentation "options" were followed by independent preformatted
paragraphs. Now they are associated plain text paragraphs. The
difference is clear in the generated html.
---
Documentation/git-grep.txt | 14 +++++++-------
Documentation/git-whatchanged.txt | 6 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
b833629d00b95554b23d2239cf8d42262a7a6db6
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index fbd2394..d55456a 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -24,13 +24,13 @@ OPTIONS
<option>...::
Either an option to pass to `grep` or `git-ls-files`.
-
- The following are the specific `git-ls-files` options
- that may be given: `-o`, `--cached`, `--deleted`, `--others`,
- `--killed`, `--ignored`, `--modified`, `--exclude=*`,
- `--exclude-from=*`, and `--exclude-per-directory=*`.
-
- All other options will be passed to `grep`.
++
+The following are the specific `git-ls-files` options
+that may be given: `-o`, `--cached`, `--deleted`, `--others`,
+`--killed`, `--ignored`, `--modified`, `--exclude=\*`,
+`--exclude-from=\*`, and `--exclude-per-directory=\*`.
++
+All other options will be passed to `grep`.
<pattern>::
The pattern to look for. The first non option is taken
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
index f02f939..641cb7e 100644
--- a/Documentation/git-whatchanged.txt
+++ b/Documentation/git-whatchanged.txt
@@ -47,9 +47,9 @@ OPTIONS
By default, differences for merge commits are not shown.
With this flag, show differences to that commit from all
of its parents.
-
- However, it is not very useful in general, although it
- *is* useful on a file-by-file basis.
++
+However, it is not very useful in general, although it
+*is* useful on a file-by-file basis.
Examples
--------
--
1.2.GIT
--
Francis Daly francis@daoine.org
^ permalink raw reply related
* Re: What's in git.git
From: Bertrand Jacquin @ 2006-03-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodzzb5q3.fsf@assigned-by-dhcp.cox.net>
On 3/22/06, Junio C Hamano <junkio@cox.net> wrote:
>
> A new configuration option, 'core.warnambiguousrefs', can be
> set to warn you if you use "frotz" to name a ref when you
> have more than one "frotz" under $GIT_DIR/refs (e.g. you have
> both branch "frotz" and tag "frotz", and/or you have
> refs/remotes/frotz/HEAD).
Ah cool :) I had the problem recently.
Also, Would could I know all configuration option ?
--
Beber
#e.fr@freenode
^ permalink raw reply
* [PATCH] Cogito: Allow https:// URLs
From: Dennis Stosberg @ 2006-03-22 11:45 UTC (permalink / raw)
To: git
Hello,
Two trivial changes allow Cogito to pull from and push to https://
URLs. The list of available transports in cg-branch-add is being
updated as well.
Thanks,
Dennis
[Please CC me, I'm not subscribed to this list]
---
cg-branch-add | 6 ++++--
cg-fetch | 2 +-
cg-push | 2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/cg-branch-add b/cg-branch-add
index 4cb5a26..6c7b222 100755
--- a/cg-branch-add
+++ b/cg-branch-add
@@ -27,10 +27,12 @@
#
# 3. HTTP - `http://host/path`
#
-# 4. SSH - `git+ssh://host/path` or `host:path` (the latter can change);
+# 4. HTTPS - `https://host/path`
+#
+# 5. SSH - `git+ssh://host/path` or `host:path` (the latter can change);
# note that the path must be absolute in the first case.
#
-# 5. GIT-Daemon - `git://host/path` - this won't clone tags.
+# 6. GIT-Daemon - `git://host/path` - this won't clone tags.
#
#
# The URL can have a fragment part, which identifies a branch inside of
diff --git a/cg-fetch b/cg-fetch
index 9f41124..e8a51e8 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -288,7 +288,7 @@ orig_head=
packed_transport=
-if echo "$uri" | grep -q "^http://"; then
+if echo "$uri" | grep -q "^https\?://"; then
get=get_http
fetch=fetch_http
elif echo "$uri" | grep -q "^git+ssh://"; then
diff --git a/cg-push b/cg-push
index fb212db..b6b8954 100755
--- a/cg-push
+++ b/cg-push
@@ -68,7 +68,7 @@ if echo "$uri" | grep -q '#'; then
fi
sprembranch=":refs/heads/$rembranch"
-if [ "${uri#http://}" != "$uri" ]; then
+if [ "${uri#http://}" != "$uri" -o "${uri#https://}" != "$uri" ]; then
# git-http-push doesn't like $sprembranch
git-http-push "$uri/" "$locbranch:$rembranch"
elif [ "${uri#git+ssh://}" != "$uri" ]; then
--
1.2.GIT
^ permalink raw reply related
* Re: What's in git.git
From: Petr Baudis @ 2006-03-22 11:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodzzb5q3.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Mar 22, 2006 at 02:58:28AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> When --use-separate-remote is in effect, the tracking
> branches are created in $GIT_DIR/refs/remotes/origin/ and you
> will not get the extra "origin" head. Your local branch
> namespace under $GIT_DIR/refs/heads/ will only have "master".
> In addition, a symref $GIT_DIR/refs/remotes/origin/HEAD
> points at the primary branch of the remote repository.
> Similar to a filename in $GIT_DIR/refs/{heads,tags} that can
> be used to name a ref (e.g. when you say "git diff frotz",
> you are telling git to read from $GIT_DIR/refs/heads/frotz
> and use that commit ID to diff your working tree against), a
> directory that has such a symref under $GIT_DIR/refs/remotes
> can be used to name the ref. IOW, "git diff origin" in a
> repository a cloned this way means you want a diff against
> $GIT_DIR/refs/remotes/origin/HEAD.
Sounds very good.
> A new configuration option, 'core.warnambiguousrefs', can be
> set to warn you if you use "frotz" to name a ref when you
> have more than one "frotz" under $GIT_DIR/refs (e.g. you have
> both branch "frotz" and tag "frotz", and/or you have
> refs/remotes/frotz/HEAD).
Is there any reason why this isn't enabled by default?
--
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
* Errors GITtifying GCC and Binutils
From: Jan-Benedict Glaw @ 2006-03-22 13:33 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 5811 bytes --]
Hi!
I'm currently working a lot with Binutils and GCC and wanted to import
those two projects into GIT trees, but both of them failed. If anybody
wants to have access to the half-finished GIT trees, please let me
know:
This is with GIT as of yesterday evening:
Binutils
~~~~~~~~
$ /home/jbglaw/bin/git cvsimport -v -d :pserver:anoncvs@sourceware.org:/cvs/src -C src src
[...]
Update gdb/testsuite/ChangeLog: 230971 bytes
Fetching gdb/testsuite/gdb.base/annota1.exp v 1.1.1.2
Update gdb/testsuite/gdb.base/annota1.exp: 14656 bytes
Fetching gdb/testsuite/gdb.base/annota2.cc v 1.1.1.3
Update gdb/testsuite/gdb.base/annota2.cc: 238 bytes
Fetching gdb/testsuite/gdb.base/annota2.exp v 1.1.1.2
Update gdb/testsuite/gdb.base/annota2.exp: 8639 bytes
Fetching sim/mcore/ChangeLog v 1.1.1.5
Update sim/mcore/ChangeLog: 1325 bytes
Fetching sim/mcore/interp.c v 1.1.1.5
Update sim/mcore/interp.c: 47368 bytes
Tree ID 640f8ff80e14257bc73fa0c3344504c4db960655
Parent ID ac9471abd876476724dc0205272b0565c18b1a7c
Committed patch 102 (SNAPSHOT 1999-05-25 18:00:33)
Commit ID 5847cc095ce0445eb6bf9df1203ccdad35f501fe
Created tag 'gdb-1999-05-25' on 'SNAPSHOT'
Switching from SNAPSHOT to origin
Fetching bfd/ChangeLog v 1.19
Update bfd/ChangeLog: 118751 bytes
Fetching bfd/elf32-arm.h v 1.4
Update bfd/elf32-arm.h: 90491 bytes
Tree ID 5100b5c49ef78e1027b476f4dbdebeca0b01f113
Parent ID 8d35c43246f8d9693203ef6a87aabf378593bceb
Committed patch 103 (origin 1999-05-26 08:27:37)
Commit ID bb18137d43506ccc7f78da63b18d9f6b6749264d
Fetching include/opcode/ChangeLog v 1.4
Update include/opcode/ChangeLog: 63395 bytes
Fetching include/opcode/hppa.h v 1.2
Update include/opcode/hppa.h: 23271 bytes
Tree ID 7b211af5cb99cbe307d02d72c1e144f3c1aac7e9
Parent ID bb18137d43506ccc7f78da63b18d9f6b6749264d
Committed patch 104 (origin 1999-05-26 16:04:10)
Commit ID 4da3ef4d311fc62a1a0bba8b680595ad824a7e2c
Fetching ld/ChangeLog v 1.11
Update ld/ChangeLog: 328968 bytes
Fetching ld/emulparams/armelf_oabi.sh v 1.2
Update ld/emulparams/armelf_oabi.sh: 585 bytes
Tree ID fcc05a0f9c66693e5b26a5fb4821f6bbeadf4c31
Parent ID 4da3ef4d311fc62a1a0bba8b680595ad824a7e2c
Committed patch 105 (origin 1999-05-26 17:23:31)
Commit ID ddaaceeede7f9bb938188c4f72ddce420d08efad
Switching from origin to gdb-4_18-branch
usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
read-tree failed: 33024
$ /home/jbglaw/bin/git cvsimport -v -d :pserver:anoncvs@sourceware.org:/cvs/src -C src src
usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
read-tree failed: 33024
GCC
~~~
$ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
[...]
... 3930 trunk/gcc/combine.c ...
Tree ID 2af6a2f6e28835fec0aaf60d278e356d12d9ae5f
Merge parent branch: 587bbd00ea5b0f8c18d8ca58bbfcaa4b6b62ff92
Committed change 3930:/ 1993-03-30 20:37:29)
Commit ID 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d
Writing to refs/heads/origin
DONE: 3930 origin 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d
... 3931 trunk/gcc/config/mips/mips.h ...
Tree ID f173f836adf4d8efb42c180d7cd5a786a3acf361
Merge parent branch: 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d
Committed change 3931:/ 1993-03-30 21:50:50)
Commit ID 7c132f1464d27bd8198c51913b17a0534376e3e6
Writing to refs/heads/origin
DONE: 3931 origin 7c132f1464d27bd8198c51913b17a0534376e3e6
... 3932 trunk/gcc/config/pa/pa.md ...
Tree ID a88f5523f982dbac1334b78c47fd56a685640a46
Merge parent branch: 7c132f1464d27bd8198c51913b17a0534376e3e6
Committed change 3932:/ 1993-03-30 22:02:05)
Commit ID 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96
Writing to refs/heads/origin
DONE: 3932 origin 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96
... 3933 trunk/gcc/real.c ...
Tree ID 7d25a64013b301e0e575587a5adfd8b540b4c5a7
Merge parent branch: 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96
Committed change 3933:/ 1993-03-31 05:30:24)
Commit ID 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6
Writing to refs/heads/origin
DONE: 3933 origin 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6
... 3934 trunk/gcc/real.h ...
Tree ID fce52e724f0f1543abd5bd430a11822c3977e803
Merge parent branch: 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6
Committed change 3934:/ 1993-03-31 05:39:37)
Commit ID f8dad6fb5af69122823800ca974e16d4f09906c2
Writing to refs/heads/origin
DONE: 3934 origin f8dad6fb5af69122823800ca974e16d4f09906c2
... 3935 trunk/gcc/Makefile.in ...
Tree ID 7c2cd41d922407ab1df47954fb82964ad7511328
Merge parent branch: f8dad6fb5af69122823800ca974e16d4f09906c2
Committed change 3935:/ 1993-03-31 05:41:37)
Commit ID eb99aa0ad37564c2071fe4b2f539fe072a72ad4c
Writing to refs/heads/origin
DONE: 3935 origin eb99aa0ad37564c2071fe4b2f539fe072a72ad4c
... 3936 trunk/gcc/c-lex.c ...
Tree ID 90547e4ef900e45f4354aa036f216a3bff93c8dd
Merge parent branch: eb99aa0ad37564c2071fe4b2f539fe072a72ad4c
Committed change 3936:/ 1993-03-31 05:44:03)
Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e
Writing to refs/heads/origin
DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e
... 3937 trunk/gcc/final.c ...
Can't fork at /home/jbglaw/bin/git-svnimport line 379.
$ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
Use of uninitialized value in system at /home/jbglaw/bin/git-svnimport line 295.
usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
read-tree failed: 33024
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Andreas Ericsson @ 2006-03-22 13:36 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060322025921.1722.qmail@science.horizon.com>
linux@horizon.com wrote:
> If someone feels ambitious, you can detect this condition automatically
> by searching for a file that you know won't be there and seeing if you
> get a 404 response to that.
>
> To avoid punishing good servers, it would be nice to defer the test
> until reciving the first corrupted object.
>
> I'm not sure what the best "object that's not supposed to be there" is.
.git/objects/00/hoping-for-a-404-or-webadmin-should-fix
It has the right number of chars so it should fit in wherever a real
object name does but is obviously bogus anyways.
> It could just be a random hash, or would a malformed object file name
> be better?
A malformed object name is infinitely better. Otherwise we'd end up with
a wild guess that hits home some day, to much surprise and a bug-report
I wouldn't want to track. Not to mention the embarrassment when
explaining why that object-name was chosen.
>
> (As an aside, I suspect this is all caused by Microsoft's "friendly HTML
> error messages" invention.)
The body of the 404-page has absolutely nothing to do with it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-03-22 16:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7v64m7av6o.fsf@assigned-by-dhcp.cox.net>
On Tue, 21 Mar 2006, Junio C Hamano wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
> >>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> >
> >>> But this wastes a commit. Is there any way to get an index that simply
> >>> includes the file from that other branch?
> >
> > Junio> $ git checkout master
> > Junio> $ git checkout next git-cvsimport.perl
> >
> > Yow. How simple is *that*? Thanks.
>
> There is one thing you would want to be careful about.
> This updates the index.
Yes. Btw, I've been bitten by that. I think it might be better to _not_
update the index when we check out a file from another branch than the one
we're on (or rather, we should perhaps update the index with the value
from the current branch every time, even though the _working_tree_ is
updated from another branch)
Linus
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Nick Hengeveld @ 2006-03-22 17:22 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060322025921.1722.qmail@science.horizon.com>
On Tue, Mar 21, 2006 at 09:59:21PM -0500, linux@horizon.com wrote:
> If someone feels ambitious, you can detect this condition automatically
> by searching for a file that you know won't be there and seeing if you
> get a 404 response to that.
It might be feasible to detect this condition using the Content-Type:
header in the server response. So far, all the GIT repositories I've
tried return text/plain for loose objects and a special 404 page will
likely be text/html.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Nick Hengeveld @ 2006-03-22 18:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060322172227.GO3997@reactrix.com>
On Wed, Mar 22, 2006 at 09:22:27AM -0800, Nick Hengeveld wrote:
> It might be feasible to detect this condition using the Content-Type:
> header in the server response. So far, all the GIT repositories I've
> tried return text/plain for loose objects and a special 404 page will
> likely be text/html.
Something like this:
http_fetch: report text/html responses for loose objects
Some HTTP server environments return a 200 status and text/html error
document or a redirect to one rather than a 404 status if a loose
object does not exist. This patch detects and reports this condition
to differentiate between a misconfigured server and an actual corrupt
object on the server.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
61069cc348640fef2b8c503b8b8f00f689872cab
diff --git a/http-fetch.c b/http-fetch.c
index dc67218..ee5b585 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -41,6 +41,7 @@ struct object_request
CURLcode curl_result;
char errorstr[CURL_ERROR_SIZE];
long http_code;
+ char *content_type;
unsigned char real_sha1[20];
SHA_CTX c;
z_stream stream;
@@ -258,9 +259,15 @@ static void finish_object_request(struct
static void process_object_response(void *callback_data)
{
+ char *content_type;
struct object_request *obj_req =
(struct object_request *)callback_data;
+ curl_easy_getinfo(obj_req->slot->curl, CURLINFO_CONTENT_TYPE,
+ &content_type);
+ if (content_type)
+ obj_req->content_type = strdup(content_type);
+
obj_req->curl_result = obj_req->slot->curl_result;
obj_req->http_code = obj_req->slot->http_code;
obj_req->slot = NULL;
@@ -298,6 +305,8 @@ static void release_object_request(struc
entry->next = entry->next->next;
}
+ if (obj_req->content_type)
+ free(obj_req->content_type);
free(obj_req->url);
free(obj_req);
}
@@ -340,6 +349,7 @@ void prefetch(unsigned char *sha1)
memcpy(newreq->sha1, sha1, 20);
newreq->repo = alt;
newreq->url = NULL;
+ newreq->content_type = NULL;
newreq->local = -1;
newreq->state = WAITING;
snprintf(newreq->filename, sizeof(newreq->filename), "%s", filename);
@@ -836,7 +846,14 @@ static int fetch_object(struct alt_base
obj_req->http_code, hex);
} else if (obj_req->zret != Z_STREAM_END) {
corrupt_object_found++;
- ret = error("File %s (%s) corrupt", hex, obj_req->url);
+ if (obj_req->content_type &&
+ !strcmp(obj_req->content_type, "text/html")) {
+ ret = error("text/html response for file %s (%s)",
+ sha1_to_hex(obj_req->sha1), obj_req->url);
+ } else {
+ ret = error("File %s (%s) corrupt",
+ sha1_to_hex(obj_req->sha1), obj_req->url);
+ }
} else if (memcmp(obj_req->sha1, obj_req->real_sha1, 20)) {
ret = error("File %s has bad hash", hex);
} else if (obj_req->rename < 0) {
--
1.2.4.gb1bc1d-dirty
^ permalink raw reply related
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-22 19:05 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060322183621.GP3997@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Some HTTP server environments return a 200 status and text/html error
> document or a redirect to one rather than a 404 status if a loose
> object does not exist. This patch detects and reports this condition
> to differentiate between a misconfigured server and an actual corrupt
> object on the server.
> 61069cc348640fef2b8c503b8b8f00f689872cab
> diff --git a/http-fetch.c b/http-fetch.c
> index dc67218..ee5b585 100644
> --- a/http-fetch.c
> +++ b/http-fetch.c
> @@ -41,6 +41,7 @@ struct object_request
> CURLcode curl_result;
>...
> + char *content_type;
> unsigned char real_sha1[20];
>...
You probably need only one bit here,...
> @@ -258,9 +259,15 @@ static void finish_object_request(struct
>
> static void process_object_response(void *callback_data)
>...
> + curl_easy_getinfo(obj_req->slot->curl, CURLINFO_CONTENT_TYPE,
> + &content_type);
> + if (content_type)
> + obj_req->content_type = strdup(content_type);
> +
... and note if that is an HTML document or not.
We do bend backwards to support ISP HTTP servers, but this might
be going a bit too far. Also I wonder if ISP runs a really
dumb-friendly configured server that defaults to text/html
unless the mimemap says otherwise. Loose object files do not
have suffixes and I am expecting these servers would give
whatever the server default is.
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-22 19:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060322115218.GT18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> A new configuration option, 'core.warnambiguousrefs', can be
>> set to warn you if you use "frotz" to name a ref when you
>> have more than one "frotz" under $GIT_DIR/refs (e.g. you have
>> both branch "frotz" and tag "frotz", and/or you have
>> refs/remotes/frotz/HEAD).
>
> Is there any reason why this isn't enabled by default?
Not in particular, other than Inertia and trying one baby step
at a time.
^ permalink raw reply
* Re: [PATCH] Format tweaks for asciidoc.
From: Junio C Hamano @ 2006-03-22 19:16 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060322095357.GA27793@craic.sysops.org>
Thanks.
One request, though. Next time please sign-off your patch.
^ 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