* 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
* Proper Publishing of a Repository
From: Jon Loeliger @ 2006-03-22 19:17 UTC (permalink / raw)
To: Git List
Folks,
So, I feel like I missed a step in the grand
"How To Publish A Repository" scheme of things.
I made a repo visible over on jdl.com. No problem.
But cloning it took forever. So I ran "git-repack"
on it. Now cloning only takes hours, not forever.
All this on the linux kernel over HTTP.
Did I miss a step somewhere?
Thanks,
jdl
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-22 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslpa8fld.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> 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.
Clarification. Even if a server configured as such existed and
sent an otherwise valid loose object with text/html, your code
does the right thing.
However the patch would not help when such a server also did a
"Sorry, did you mistype the URL?" HTML response, and I was
wondering how typical that would be.
^ permalink raw reply
* Best way to generate a git tree containing only a subset of commits from another tree?
From: Anton Altaparmakov @ 2006-03-22 19:28 UTC (permalink / raw)
To: git
As subject, what is at present the best way to generate a git tree
containing only a subset of commits from another tree.
So I have /usr/src/my-big-tree and /usr/src/linux-2.6 and now I want to
add some of the commits in my-big-tree to the tree linux-2.6 so I can push
out to Linus.
Preferable I would like to do it so that later when Linus has pulled from
my /usr/src/linux-2.6 tree, I do a "git pull" of Linus' tree from
/usr/src/my-big-tree and it all works correctly and I don't end up with
the same commits twice.
Is that possible at all?
If not what can I do to do it cleanly? Does git help in any way or do I
literally have to export all my commits from /usr/src/my-big-tree to diff
style patches and then throw away the tree, clone Linus tree after he has
pulled my /usr/src/linux-2.6 tree and commit all my generated diff patches
again? That would be rather horrible to have to do...
I am happy to be pointed to a FAQ or RTFM if you tell me where to look for
it...
Thanks a lot in advance!
PS. Please keep me CC:-ed as I am not on the git mailing list any more.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: Proper Publishing of a Repository
From: Timo Hirvonen @ 2006-03-22 20:16 UTC (permalink / raw)
To: git
In-Reply-To: <1143055072.4527.142.camel@cashmere.sps.mot.com>
On Wed, 22 Mar 2006 13:17:52 -0600
Jon Loeliger <jdl@freescale.com> wrote:
> Folks,
>
> So, I feel like I missed a step in the grand
> "How To Publish A Repository" scheme of things.
>
> I made a repo visible over on jdl.com. No problem.
> But cloning it took forever. So I ran "git-repack"
> on it. Now cloning only takes hours, not forever.
>
> All this on the linux kernel over HTTP.
Use git:// protocol (git-daemon) if possible. It is much faster.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Fix multi-paragraph list items in OPTIONS section
From: Jonas Fonseca @ 2006-03-22 20:03 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060320104118.GA32151@craic.sysops.org>
Francis Daly <francis@daoine.org> wrote Mon, Mar 20, 2006:
> On Mon, Mar 20, 2006 at 10:39:46, Jonas Fonseca wrote:
>
> > Asciidoc cannot handle multi-paragraph description list items without the
> > need for adding special control characters and reindenting all paragraphs
> > but the first.
>
> This issue affects the display of current git-cvsimport and
> git-svnimport doc pages. There was a general tidy-up done in
> df8baa42fe4eeb5a021ac262caf601f44d2a5746 last October, but additions
> since then didn't keep the layout.
I think we are only a few people who cares about this and the vast
number of git manpages makes it very time consuming to keep the layout
polished. Personally, I care mostly for the git core manpages. Maybe if
they lived in a separate directory from the git porcelain manpages it
would be easier to get them into a better shape.
> I don't think there is a full "fix" for this; either the html docs are
> ugly (see the -A section in the pages mentioned above as they are now),
> or the asciidoc source files look odd (although that's probably not a
> big problem) or the manpages look a bit funny.
I found the same thing. Getting both good HTML and manpages is not
trivial unless you use only limited and simple markup. Some things
supported by the HTML generator is not available or doesn't turn out as
good in the generated manpages. This was the main reason I decided to
add a special script to strip/convert markup when generating the cg-ref
manpages.
As for the odd looking asciidoc sources, you can always generate a clean
text version. BTW, for lists you can get rid of the '+' continuations
tags by embedding the list in a pair of '--'. It makes the resulting
source a little more readable.
--
- item 1, para 1
item 1, para 2
- item 2
--
--
Jonas Fonseca
^ permalink raw reply
* Re: Proper Publishing of a Repository
From: Jon Loeliger @ 2006-03-22 20:26 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Git List
In-Reply-To: <20060322221630.e65baca0.tihirvon@gmail.com>
On Wed, 2006-03-22 at 14:16, Timo Hirvonen wrote:
> On Wed, 22 Mar 2006 13:17:52 -0600
> Jon Loeliger <jdl@freescale.com> wrote:
>
> > Folks,
> >
> > So, I feel like I missed a step in the grand
> > "How To Publish A Repository" scheme of things.
> >
> > I made a repo visible over on jdl.com. No problem.
> > But cloning it took forever. So I ran "git-repack"
> > on it. Now cloning only takes hours, not forever.
> >
> > All this on the linux kernel over HTTP.
>
> Use git:// protocol (git-daemon) if possible. It is much faster.
Trust me, if it were an option, I would. It isn't.
So, I think git-prune-packed was the answer here...
jdl
^ permalink raw reply
* Re: Proper Publishing of a Repository
From: Junio C Hamano @ 2006-03-22 20:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1143059181.4527.162.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> On Wed, 2006-03-22 at 14:16, Timo Hirvonen wrote:
>> Jon Loeliger <jdl@freescale.com> wrote:
>>
>> > All this on the linux kernel over HTTP.
>>
>> Use git:// protocol (git-daemon) if possible. It is much faster.
>
> Trust me, if it were an option, I would. It isn't.
>
> So, I think git-prune-packed was the answer here...
It really depends on who your audiences are. By packing
everything in a single pack, you are optimizing for the initial
cloners but punishing incremental updaters.
Since your tree is derived from Linus tree, anybody who is
interested in your tree is very likely nterested in Linus tree
and chances are that she has a recent copy of it locally. In
such a case, I would not be surprised if:
$ git clone -l -s -n /local-linux-2.6.git/ jdl-linux.git
$ cd jdl-linux.git
$ git fetch http://jdl.com/jdl-linux.git master:refs/heads/jdl
goes a lot faster if you have loose objects around in the
repository.
^ permalink raw reply
* Re: Question about possible git races
From: Radoslaw Szkodzinski @ 2006-03-22 20:46 UTC (permalink / raw)
To: git
In-Reply-To: <200603201724.12442.astralstorm@o2.pl>
[-- Attachment #1: Type: text/plain, Size: 538 bytes --]
On Monday 20 March 2006 17:24, Radoslaw Szkodzinski wrote yet:
> I'd like to write a multithreaded application using git, so I'd like to see
> if there are any races:
>
> - push vs fetch
> ...
> - push vs push
> ...
> - fetch vs fetch
> ...
>
> I'm meaning really bare git there, w/o bash+perl scripts.
Could anyone try to answer the question?
I'd really like to know, because it's crucial to my application.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Radoslaw Szkodzinski @ 2006-03-22 21:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nick Hengeveld
In-Reply-To: <7vslpa8fld.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
On Wednesday 22 March 2006 20:05, Junio C Hamano wrote yet:
>
> .. and note if that is an HTML document or not.
>
Better yet, see first if the object is corrupt. If it is and its Content-Type
is text/html, error out.
> 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.
That server would break a *lot* of file types. That admin should be hanged,
shot, then burned.
I think of only one reason for doing that: to restrict file types posted on
the server to, say, zip and html.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ 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