* Re: Errors GITtifying GCC and Binutils
From: sean @ 2006-03-23 22:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>
On Thu, 23 Mar 2006 12:38:33 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> Actually, as far as I can tell, git already has a hell of a lot more
> porcelain than pretty much any non-IDE type traditional SCM. Certainly
> more than CVS.
>
> Yeah, I'm not counting things like Eclipse etc. I'm talking about "plain
> SCM" environments, ie just basic SVN or CVS. What are we missing in that
> department? (The only thing I can think of is a diff colorizer, which some
> prople seem to really want).
Yeah, i was thinking more along the lines of the way cogito handles
commit message editing for example, where you can change which files
are committed by editing the file list in place. Maybe the colorized
git log viewer would be worth pulling into core as well, etc.
It's been a long time since i've looked at cogito but perhaps there
are other things in it that have proven useful and deserve to
be pushed into core.
I guess my original comment was made because I always cringe when
i see git described as "plumbing" and only having porcelain-"ish"
commands included.
Sean
^ permalink raw reply
* Re: [PATCH] doc: add clarification of existing GPLv2 license terms to manual pages
From: Petr Baudis @ 2006-03-23 21:57 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20060323015847.4624.61707.stgit@localhost.localdomain>
Dear diary, on Thu, Mar 23, 2006 at 02:58:50AM CET, I got a letter
where Sam Vilain <sam.vilain@catalyst.net.nz> said that...
> The GPLv3 is less ambiguous on these things, but a decision on the use
> of GPLv3 has already been deferred.
Was it?
My fulltext =git mailbox search doesn't yield any matches at all.
--
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: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 21:48 UTC (permalink / raw)
To: David S. Miller; +Cc: seanlkml, keithp, hpa, jbglaw, git
In-Reply-To: <20060323.133120.69312511.davem@davemloft.net>
On Thu, 23 Mar 2006, David S. Miller wrote:
>
> > Yeah, I'm not counting things like Eclipse etc. I'm talking about "plain
> > SCM" environments, ie just basic SVN or CVS. What are we missing in that
> > department? (The only thing I can think of is a diff colorizer, which some
> > prople seem to really want).
>
> gitk does color the diffs already, or are we talking about some
> "side-by-side" multiple window thing showing "before" on the
> left and "after" on the right?
I think we're just talking about
git diff | git colorize
like this (and then integrating it a bit better).
Linus
--- colorize.c ---
#include "cache.h"
#define BUFSIZE 128
#define NORMAL ""
#define BOLD "\033[1m"
#define UL "\033[4m"
#define GRAYBG "\033[47m"
#define BLACK "\033[30m"
#define RED "\033[31m"
#define GREEN "\033[32m"
#define YELLOW "\033[33m"
#define BLUE "\033[34m"
#define MAGENTA "\033[35m"
#define CYAN "\033[36m"
#define WHITE "\033[37m"
#define RESET "\033[m"
enum linetype {
UNKNOWN,
HEAD,
FRAGHEAD,
ADD,
REMOVE,
UNCHANGED,
};
static const char *tput[][2] = {
[UNKNOWN] = { NORMAL, NORMAL "\n" },
[HEAD] = { BOLD, RESET "\n" },
[FRAGHEAD] = { GRAYBG, RESET "\n" },
[ADD] = { GREEN, RESET "\n" },
[REMOVE] = { RED, RESET "\n" },
[UNCHANGED] = { NORMAL, NORMAL "\n" },
};
static void colorize(FILE *in, FILE *out)
{
char buffer[BUFSIZE];
const char *end = NULL;
int in_fragment = 0;
while (fgets(buffer, BUFSIZE, in)) {
int type = UNKNOWN;
int eoln, len = strlen(buffer);
const char *begin;
if (!len)
break;
eoln = buffer[len-1] == '\n';
if (eoln)
buffer[--len] = 0;
/* Did we have a partial line from before? */
if (end) {
fputs(buffer, out);
if (!eoln)
continue;
fputs(end, out);
end = NULL;
continue;
}
if (in_fragment) {
in_fragment--;
switch (buffer[0]) {
case '+':
type = ADD;
break;
case '-':
type = REMOVE;
break;
case ' ':
type = UNCHANGED;
break;
case '\\':
type = UNCHANGED;
break;
default:
in_fragment = 0;
}
}
if (type == UNKNOWN) {
if (!strncmp(buffer, "@@ ", 3)) {
type = FRAGHEAD;
/* We should parse the line numbers */
in_fragment = INT_MAX;
}
if (!strncmp(buffer, "+++ ", 4) ||
!strncmp(buffer, "--- ", 4) ||
!strncmp(buffer, "diff ", 5))
type = HEAD;
}
begin = tput[type][0];
end = tput[type][1];
fputs(begin, out);
fputs(buffer, out);
if (!eoln)
continue;
fputs(end, out);
end = NULL;
}
if (end)
fputs(end, out);
}
int main(int argc, char **argv)
{
colorize(stdin, stdout);
return 0;
}
^ permalink raw reply
* Re: [RFC] Silent File Mods Being Committed
From: Petr Baudis @ 2006-03-23 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vek0t68we.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Mar 23, 2006 at 06:13:21AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> (2) audit all the scripts to make sure they do not get upset if
> we add trailing +/- to the status letter, and do that
> unconditionally, like the attached patch does.
Cogito will get upset since we assume the mode field is one-char in our
regexps, and when we don't, we compare the mode field with strings and
that would obviously fail if you add random stuff to it.
Otherwise, I like this idea, 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: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 21:39 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Keith Packard, H. Peter Anvin, Jan-Benedict Glaw, git
In-Reply-To: <20060323210215.GH26071@mythryan2.michonline.com>
On Thu, 23 Mar 2006, Ryan Anderson wrote:
>
> Scott Collins (QT evangelist, incredibly smart guy) commented to me
> sometime over the summer, that every new SCM was born out of someone's
> desire to implement a new merge algorithm. While I think that's too
> simple, I think there have been an awful lot of academic SCMs out there.
The exact details are lost in antiquity, but I'm sure one of the defining
moments in time for CVS was Dick Grune saying "Merges? We don't need no
steenking merges! We'll just make branching difficult! Yeah, that's it!
Mwhahahhahhaaaa!".
The rest is history.
[ Really, the sad part is that you're probably right even when it comes to
CVS. The #1 feature of CVS as defined by Brian Berliner in his CVS II
paper was 'Concurrent access and conflict-resolution algorithms to
guarantee that source changes are not "lost"'. ]
Linus
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: David S. Miller @ 2006-03-23 21:31 UTC (permalink / raw)
To: torvalds; +Cc: seanlkml, keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>
From: Linus Torvalds <torvalds@osdl.org>
Date: Thu, 23 Mar 2006 12:38:33 -0800 (PST)
> Yeah, I'm not counting things like Eclipse etc. I'm talking about "plain
> SCM" environments, ie just basic SVN or CVS. What are we missing in that
> department? (The only thing I can think of is a diff colorizer, which some
> prople seem to really want).
gitk does color the diffs already, or are we talking about some
"side-by-side" multiple window thing showing "before" on the
left and "after" on the right?
Given that the gitk author has also written diff colorizers in the
past, I don't see providing this as being much of a problem :)
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Ryan Anderson @ 2006-03-23 21:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20060323204825.GE30176@spearce.org>
On Thu, Mar 23, 2006 at 03:48:25PM -0500, Shawn Pearce wrote:
>
> But your definately right; once the blame/annotate war settles out
> GIT will have pretty much everything one might need - except a good
> distributed bug/issue tracking type system. :-)
Junio, where do we stand on this?
I've been a bit busy to finish the bug fixing I need to do on
annotate[1], and frankly, I have no strong feelings either way.
I must admit, I find annotate easier to read, but I wrote it, so I'm a
bit biased. Maybe it is just that in C you sometimes get lost in the
details.
1 - The only bug I'm aware of, at the moment, is the fact that merges
sometimes get assigned poorly, which I have a plan to fix, I just
haven't had the time to sort it out yet.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Ryan Anderson @ 2006-03-23 21:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Keith Packard, H. Peter Anvin, Jan-Benedict Glaw, git
In-Reply-To: <Pine.LNX.4.64.0603230758260.26286@g5.osdl.org>
On Thu, Mar 23, 2006 at 08:01:14AM -0800, Linus Torvalds wrote:
> On Thu, 23 Mar 2006, Keith Packard wrote:
> >
> > Note that vendor branches are always made from the first revision along
> > a branch, independent of when they occur, so you'll get 1.1.3.1 even if
> > the head revision along the trunk is 1.246.
>
> I have to say, that one thing I've learnt during this whole git thing is
> that other SCM's are DAMN CONFUSED.
>
> I used to think that git was potentially hard to understand. Not so. git
> is an absolute paragon of logic and easy-to-understand concepts.
>
> Compared to SVN (can anybody sat "trunk/branch/tag confusion") and CVS,
> git is not only a hell of a lot more capable, it's just more logical.
This might be somewhat controversial, and I haven't done any research to
confirm my impression, but you might be just seeing the symptoms of
different ways of looking at the problem.
Scott Collins (QT evangelist, incredibly smart guy) commented to me
sometime over the summer, that every new SCM was born out of someone's
desire to implement a new merge algorithm. While I think that's too
simple, I think there have been an awful lot of academic SCMs out there.
Git has taken a very pragmatic approach, in that the goal has been "What
is the smallest number of concepts we can create that let us solve the
problem, even if we occassionally have to make some tradeoffs?"
(Thinking of rename detection there, mostly.)
So, really, I guess the comment I'm trying to make here is that Occam
was right.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Question about possible git races
From: Radoslaw Szkodzinski @ 2006-03-23 20:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44220E21.7040204@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
On Thursday 23 March 2006 03:55, Andreas Ericsson wrote yet:
> Radoslaw Szkodzinski wrote:
> > On Thursday 23 March 2006 00:28, Andreas Ericsson wrote yet:
> >>Btw. I'm assuming you're aware you'll have to GPL this app of yours,
> >>since git is GPL and you'll be using the git produce in a way that makes
> >>it vital to your app.
> >
> > It will be, but not because of git (it's execve()ing it), but rather
> > because of the principle.
>
> Ah, Good Thing. Just to clarify for the archives though, it *is*
> required since it's using git in a way that makes git a fundamental,
> non-replaceable part of its core operations.
>
> > Intermediate results will probably be:
> > - later yet another porcelain, written in C
>
> yagit? yagp? What I wanna know is when jigit's gonna hit the streets. :)
I need a memorable three-letter acronym, so it will be gip. (Git porcelain In
Python) and the C one... later.
GIP also stands for Good Informatics Practices :P or "to swindle", but it's
the deprecated usage, I think. It has some racial ties.
Conflicts with: GNOME IP calculator - http://www.debain.org/software/gip/
I'd get myself a better commandline IP calculator than give a good TLA to
this. Gnip should be the name.
What's jigit? Did I miss something?
--
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: Errors GITtifying GCC and Binutils
From: Shawn Pearce @ 2006-03-23 20:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sean, keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Thu, 23 Mar 2006, sean wrote:
> >
> > lol, that sounds like a really good plan. Perhaps as a two pronged effort
> > its worth changing the notion that git is primarily "plumbing". Adding
> > some of the nice features of cogito and other "porcelains" into the core
> > git might go a ways toward converting the few naysayers we don't kill.
>
> Actually, as far as I can tell, git already has a hell of a lot more
> porcelain than pretty much any non-IDE type traditional SCM. Certainly
> more than CVS.
>
> Yeah, I'm not counting things like Eclipse etc. I'm talking about "plain
> SCM" environments, ie just basic SVN or CVS. What are we missing in that
> department? (The only thing I can think of is a diff colorizer, which some
> prople seem to really want).
A pretty native point-and-click Windows GUI so Windows users can
use GIT without knowing how to actually use their computer. :-)
I'm not trying to bash Windows users. I'm just saying that there's
definately a large user base for SCMs such as CVS who just want
to check in the latest version of a file they have to maintain.
Many of these people are afraid of a command prompt. Asking them
to install Cygwin just to check in a file is a difficult challenge.
And even if a user is perfectly comfortable with a command prompt
and could write one-line scripts faster than anyone else, sometimes
users just prefer a GUI interface.
qgit probably comes close in this department but hasn't been packaged
up into a pretty Windows installer. :-)
But your definately right; once the blame/annotate war settles out
GIT will have pretty much everything one might need - except a good
distributed bug/issue tracking type system. :-)
--
Shawn.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-23 20:45 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060323184351.GA3892@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Seems like there are three cases to worry about:
>
> 1) the server returns a 200 status and a text/html response instead of a
> 404, and the server's default content type is not text/html
> 2) the server returns a 200 status and a text/html response instead of a
> 404, and the server's default content type is text/html
> 3) the server returns a corrupt object from the repository
> I don't think there's a way to distinguish between #2 and #3, so all we
> can really do is display as helpful an error message as possible.
The code behaves correctly the same way whether the server says
404 or 200 with human readable "No such object", and this is
just for formatting error messages, and to be honest I do not
really care at this point. I think the existing error message
at the end of transfer we added recently should be sufficient.
> On a related note, I noticed that http-fetch will continue to try
> inflating/sha1_updating the response after an inflate error has been
> detected. It's probably not a huge deal, but we could just error out
> immediately at that point or at least stop the unnecessary processing.
That would probably be more helpful.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 20:42 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060323200306.GG31387@lug-owl.de>
On Thu, 23 Mar 2006, Jan-Benedict Glaw wrote:
>
> Switching from origin to #CVSPS_NO_BRANCH
Ahh. I had some other changes to my cvsps, so I never saw this. I just
turned the #CVSPS_NO_BRANCH thing into HEAD.
Linus
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 20:38 UTC (permalink / raw)
To: sean; +Cc: keithp, hpa, jbglaw, git
In-Reply-To: <BAYC1-PASMTP0912D2287AB923F3338969AEDE0@CEZ.ICE>
On Thu, 23 Mar 2006, sean wrote:
>
> lol, that sounds like a really good plan. Perhaps as a two pronged effort
> its worth changing the notion that git is primarily "plumbing". Adding
> some of the nice features of cogito and other "porcelains" into the core
> git might go a ways toward converting the few naysayers we don't kill.
Actually, as far as I can tell, git already has a hell of a lot more
porcelain than pretty much any non-IDE type traditional SCM. Certainly
more than CVS.
Yeah, I'm not counting things like Eclipse etc. I'm talking about "plain
SCM" environments, ie just basic SVN or CVS. What are we missing in that
department? (The only thing I can think of is a diff colorizer, which some
prople seem to really want).
Linus
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Jan-Benedict Glaw @ 2006-03-23 20:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603221717120.26286@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]
On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 22 Mar 2006, Linus Torvalds wrote:
> > This one-liner to cvsps.c seems to make sure we have an ancestor branch
> > for that "gdb-4.18-branch" branch, at least according to the cvsps output.
>
> The "git cvsimport" is still running, but at least it seems to be happily
> running further past the point it broke earlier.
I've started it once again, too, with the one-liner added to Debian
unstable's version of cvsps:
Fetching gas/ChangeLog v 1.479
Update gas/ChangeLog: 250329 bytes
Tree ID a6b48ebac02a4158d37bab17c54c667223ecd971
Parent ID 4cabd2962031fd7ec6416580d84fb30a304969f3
Committed patch 3742 (origin 2000-07-29 03:23:31)
Commit ID 1910c20a44455db916a5c040663716a7389219bc
Fetching winsup/cygwin/fhandler.h v 1.16
Update winsup/cygwin/fhandler.h: 25992 bytes
Fetching winsup/cygwin/include/cygwin/cygwin_dll.h v 1.2
Update winsup/cygwin/include/cygwin/cygwin_dll.h: 3050 bytes
Fetching winsup/cygwin/lib/cygwin_crt0.c v 1.5
Update winsup/cygwin/lib/cygwin_crt0.c: 926 bytes
Tree ID 0c2c7e9d0846e5f42b0bebad8b27ce439ddefb73
Parent ID 1910c20a44455db916a5c040663716a7389219bc
Committed patch 3743 (origin 2000-07-29 04:19:24)
Commit ID a15aac16f12061fbfef1be8f21b80a5076c8d605
Fetching winsup/cygwin/ChangeLog v 1.235
Update winsup/cygwin/ChangeLog: 75391 bytes
Fetching winsup/cygwin/dtable.cc v 1.11
Update winsup/cygwin/dtable.cc: 14399 bytes
Fetching winsup/cygwin/environ.cc v 1.17
Update winsup/cygwin/environ.cc: 17190 bytes
Fetching winsup/cygwin/winsup.h v 1.22
Update winsup/cygwin/winsup.h: 15828 bytes
Tree ID f777977c2b138952bc5a9bc431eec3de99a5f7db
Parent ID a15aac16f12061fbfef1be8f21b80a5076c8d605
Committed patch 3744 (origin 2000-07-29 16:01:23)
Commit ID 38b0ed94ef1c402b7b78ac6cad6c89ce189cd223
Switching from origin to #CVSPS_NO_BRANCH
usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
read-tree failed: 33024
It seems there's a patch like
http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?
...or we need a better cvsps. Shall I add it and try again / try to
continue, or give up on it for now? Though it would be nice to have
these two large and important source trees under GIT control :-)
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: Nick Hengeveld @ 2006-03-23 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbi8eu1.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 22, 2006 at 11:22:14AM -0800, Junio C Hamano wrote:
> You probably need only one bit here,...
> ... and note if that is an HTML document or not.
/me smacks self...
> 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.
Seems like there are three cases to worry about:
1) the server returns a 200 status and a text/html response instead of a
404, and the server's default content type is not text/html
2) the server returns a 200 status and a text/html response instead of a
404, and the server's default content type is text/html
3) the server returns a corrupt object from the repository
I don't think there's a way to distinguish between #2 and #3, so all we
can really do is display as helpful an error message as possible.
We can detect #1 if there has been a previous successful loose object
transfer by tracking whether the repo's default content type is
text/html. In such a case should http-fetch behave as if the server
returned 404? If there have been no successful loose object transfers,
we'd have to respond as with #2. This approach could potentially break
if requests are load-balanced to servers with different
misconfigurations - but I think trying to detect that is bending
backwards a little too far.
On a related note, I noticed that http-fetch will continue to try
inflating/sha1_updating the response after an inflate error has been
detected. It's probably not a huge deal, but we could just error out
immediately at that point or at least stop the unnecessary processing.
Something like this? Tested by cloning
http://digilander.libero.it/mcostalba/scm/qgit.git
[PATCH] http-fetch: try to detect 404s from misconfigured servers
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 tries to detect such a response
and treat it as a 404.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 24 ++++++++++++++++++++++--
1 files changed, 22 insertions(+), 2 deletions(-)
ab97429c5b0a4b4466ee0072f75706399e42b675
diff --git a/http-fetch.c b/http-fetch.c
index dc67218..bb75050 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -16,6 +16,7 @@ struct alt_base
{
char *base;
int got_indices;
+ int default_html_content_type;
struct packed_git *packs;
struct alt_base *next;
};
@@ -41,6 +42,7 @@ struct object_request
CURLcode curl_result;
char errorstr[CURL_ERROR_SIZE];
long http_code;
+ char html_content_type;
unsigned char real_sha1[20];
SHA_CTX c;
z_stream stream;
@@ -249,6 +251,9 @@ static void finish_object_request(struct
unlink(obj_req->tmpfile);
return;
}
+ if (obj_req->repo->default_html_content_type == -1)
+ obj_req->repo->default_html_content_type =
+ obj_req->html_content_type;
obj_req->rename =
move_temp_to_file(obj_req->tmpfile, obj_req->filename);
@@ -258,9 +263,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 && !strcmp(content_type, "text/html"))
+ obj_req->html_content_type = 1;
+
obj_req->curl_result = obj_req->slot->curl_result;
obj_req->http_code = obj_req->slot->http_code;
obj_req->slot = NULL;
@@ -340,6 +351,7 @@ void prefetch(unsigned char *sha1)
memcpy(newreq->sha1, sha1, 20);
newreq->repo = alt;
newreq->url = NULL;
+ newreq->html_content_type = 0;
newreq->local = -1;
newreq->state = WAITING;
snprintf(newreq->filename, sizeof(newreq->filename), "%s", filename);
@@ -539,6 +551,7 @@ static void process_alternates_response(
newalt->next = NULL;
newalt->base = target;
newalt->got_indices = 0;
+ newalt->default_html_content_type = -1;
newalt->packs = NULL;
while (tail->next != NULL)
tail = tail->next;
@@ -835,8 +848,14 @@ static int fetch_object(struct alt_base
obj_req->errorstr, obj_req->curl_result,
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->html_content_type &&
+ !obj_req->repo->default_html_content_type)
+ ret = -1; /* Be silent, looks like a 404 */
+ else {
+ corrupt_object_found++;
+ 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) {
@@ -985,6 +1004,7 @@ int main(int argc, char **argv)
alt = xmalloc(sizeof(*alt));
alt->base = url;
alt->got_indices = 0;
+ alt->default_html_content_type = -1;
alt->packs = NULL;
alt->next = NULL;
--
1.2.4.gb1bc1d-dirty
^ permalink raw reply related
* Re: Errors GITtifying GCC and Binutils
From: sean @ 2006-03-23 18:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603230758260.26286@g5.osdl.org>
On Thu, 23 Mar 2006 08:01:14 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> I have to say, that one thing I've learnt during this whole git thing is
> that other SCM's are DAMN CONFUSED.
>
> I used to think that git was potentially hard to understand. Not so. git
> is an absolute paragon of logic and easy-to-understand concepts.
>
> Compared to SVN (can anybody sat "trunk/branch/tag confusion") and CVS,
> git is not only a hell of a lot more capable, it's just more logical.
>
> We will hereby start scouring the net for people who say git is hard to
> understand and use, and just kill them. They clearly are just polluting
> the gene pool.
lol, that sounds like a really good plan. Perhaps as a two pronged effort
its worth changing the notion that git is primarily "plumbing". Adding
some of the nice features of cogito and other "porcelains" into the core
git might go a ways toward converting the few naysayers we don't kill.
Sean
^ permalink raw reply
* Re: Who do I report bugs in the git source web browser thing to?
From: Linus Torvalds @ 2006-03-23 17:03 UTC (permalink / raw)
To: Rob Landley; +Cc: git
In-Reply-To: <200603231143.17762.rob@landley.net>
On Thu, 23 Mar 2006, Rob Landley wrote:
>
> When I go to kernel.org, click the tiny C next to linus's name to get the git
> browser for the tree, click "tree", click the "usr" directory, and then click
> "history" next to the file gen_init_cpio.c, it says this file appeared out of
> thin air 59 minutes ago.
It does?
For me, it says that the file has no history at all. Which is true. It
hasn't been changed since it was imported, and normally git doesn't show
the root commit at all (exactly because it's the "import" commit).
Now, gitweb _could_ use the "--root" flag to git-diff-tree to also show
the root commit as a diff against nothingness, and then each file would
always have at least _one_ history entry, but if you want that, you might
as well just click the "blob" button instead, that shows what the file is.
The one commit you see (the "[PATCH] reduce size of bio mempools" thing in
the header at the thing) is _not_ part of the file history: it's your
starting point for history searching. In other words, it's the top commit
that you do your history _off_.
Pick another file, like the Makefile, to see what real history looks like
(or, better yet, go into a different directory that actually sees more
real work, like kernel/, and look at the history of files there).
Linus
^ permalink raw reply
* Re: Who do I report bugs in the git source web browser thing to?
From: Josh Boyer @ 2006-03-23 16:51 UTC (permalink / raw)
To: Rob Landley; +Cc: git
In-Reply-To: <200603231143.17762.rob@landley.net>
On 3/23/06, Rob Landley <rob@landley.net> wrote:
> When I go to kernel.org, click the tiny C next to linus's name to get the git
> browser for the tree, click "tree", click the "usr" directory, and then click
> "history" next to the file gen_init_cpio.c, it says this file appeared out of
> thin air 59 minutes ago.
>
> This is not the case.
Linus' tree only goes back to 2.6.12 or so. I think you're just
seeing the fact that it's the first commit to that file since it was
initially imported.
josh
^ permalink raw reply
* Who do I report bugs in the git source web browser thing to?
From: Rob Landley @ 2006-03-23 16:43 UTC (permalink / raw)
To: git
When I go to kernel.org, click the tiny C next to linus's name to get the git
browser for the tree, click "tree", click the "usr" directory, and then click
"history" next to the file gen_init_cpio.c, it says this file appeared out of
thin air 59 minutes ago.
This is not the case.
>From this link:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;h=bc589b0ffba8941b7f7574b71ddec795e2217107;hb=b0e6e962992b76580f4900b166a337bad7c1e81b;f=usr
I wind up with this link:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;h=b0e6e962992b76580f4900b166a337bad7c1e81b;f=usr/gen_init_cpio.c
Which shows exactly one change.
Am I doing something wrong?
Rob
--
Never bet against the cheap plastic solution.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 16:01 UTC (permalink / raw)
To: Keith Packard; +Cc: H. Peter Anvin, Jan-Benedict Glaw, git
In-Reply-To: <1143128751.6850.35.camel@neko.keithp.com>
On Thu, 23 Mar 2006, Keith Packard wrote:
>
> Note that vendor branches are always made from the first revision along
> a branch, independent of when they occur, so you'll get 1.1.3.1 even if
> the head revision along the trunk is 1.246.
I have to say, that one thing I've learnt during this whole git thing is
that other SCM's are DAMN CONFUSED.
I used to think that git was potentially hard to understand. Not so. git
is an absolute paragon of logic and easy-to-understand concepts.
Compared to SVN (can anybody sat "trunk/branch/tag confusion") and CVS,
git is not only a hell of a lot more capable, it's just more logical.
We will hereby start scouring the net for people who say git is hard to
understand and use, and just kill them. They clearly are just polluting
the gene pool.
Linus
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Keith Packard @ 2006-03-23 15:45 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: keithp, Linus Torvalds, Jan-Benedict Glaw, git
In-Reply-To: <44223B90.3040500@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Wed, 2006-03-22 at 22:09 -0800, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > It _seems_ that the reason for that is that cvsps considers a revision
> > number of 1.1.1.1 to have a "dot depth" of 0, for some really strange
> > reason (it's a total special case).
> >
>
> Probably because in 99% of all cases, revision 1.1.1.1 is the result of
> a "cvs import".
All odd branches are imports. Internal branches are even. So, 1.1.3.1
would be the first import along the second vendor branch from the trunk.
Note that vendor branches are always made from the first revision along
a branch, independent of when they occur, so you'll get 1.1.3.1 even if
the head revision along the trunk is 1.246.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC] Make dot-counting ignore ".1" at the end
From: Keith Packard @ 2006-03-23 7:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603222232210.26286@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
On Wed, 2006-03-22 at 22:34 -0800, Linus Torvalds wrote:
> With that in place (the "make sure we have a proper ancestor branch"
> thing), a "git cvsimport" of the binutils tree seems to be working, at
> least to the point that it seems to have imported 1400+ commits without
> undue complaints. But hey, I'm looking forward to something less
> hacked-together.
Yeah, me too. Attempts at importing some of the X.org trees have
resulted in 'less than ideal' repositories.
I stuck a couple of hacks in cvsps myself to get it to deal with
X.org trees; the first was to increase a static buffer to 'large enough'
to hold X.org-style commit messages (which are enormous).
http://gitweb.freedesktop.org/?p=freedesktop-cvsps;a=summary
shows both minor patches. I should have let people know about these
earlier...
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC] Make dot-counting ignore ".1" at the end
From: Linus Torvalds @ 2006-03-23 6:34 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1143095182.6850.23.camel@neko.keithp.com>
On Wed, 22 Mar 2006, Keith Packard wrote:
>
> No. 1.1.1.1 is the first import on the first vendor branch; 1.1 is the
> head of the tree.
Ok. Discard the second patch. The first one is definitely needed for cvsps
right now, though.
With that in place (the "make sure we have a proper ancestor branch"
thing), a "git cvsimport" of the binutils tree seems to be working, at
least to the point that it seems to have imported 1400+ commits without
undue complaints. But hey, I'm looking forward to something less
hacked-together.
Linus
^ permalink raw reply
* Re: [RFC] Make dot-counting ignore ".1" at the end
From: Keith Packard @ 2006-03-23 6:26 UTC (permalink / raw)
To: Linus Torvalds, Git Mailing List; +Cc: keithp
In-Reply-To: <Pine.LNX.4.64.0603221746300.26286@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
On Wed, 2006-03-22 at 17:50 -0800, Linus Torvalds wrote:
> I'm not 100% sure this is appropriate, but in general, I think "<rev>" and
> "<rev>.1" should be considered the same thing, no? Which implies that
> "1.1" and "1.1.1.1" are all the same thing, and collapse to just "1", ie a
> zero dot-count. They are all the same version, after all, no?
No. 1.1.1.1 is the first import on the first vendor branch; 1.1 is the
head of the tree.
vendor branches are total CVS magic and need very special treatment. The
initial import sets the 'branch' value in the ,v file to point at the
vendor branch. Subsequent imports leave the branch value alone, a commit
to the trunk will reset the branch to point at the trunk. This means
that use of the default version of the file just after an import gives
you the head of the import tree. It's insane, but that's how it works.
What I've been doing is to treat imports to a vendor branch which occur
sequentially as if they were on the trunk. Imports after an intervening
commit to the trunk are placed on a separate branch.
The best part is that you get the vendor branch named 1.1.1 *even if
you've made a million commits to the trunk*. Which means that you must
ignore the numeric relationship between the vendor branch and the trunk
and merge them together in date order.
> This gets rid of the insane (?) special case of "1.1.1.1" that exists
> there now, since it's now no longer a special case.
Oh, it's a seriously special case, one which takes seriously special
handling, and a careful disregard for normal version number ordering.
> I also wonder if trailing ".1" revisions should be ignored when comparing
> two revisions.
As 'real' CVS version numbers always have four digits, this doesn't much
matter.
btw -- I've got my parsecvs code doing a pretty good job of discovering
the structure of an arbitrary set of ,v files. The last remaining bit of
code to write is to correctly construct the tree of branches from the
partial trees in each ,v file. With simple trees, things are looking
good, with the xserver CVS tree, I get a couple of mis-hung branches as
the branch tree is wrong. Fixed tomorrow, I think, at which point it
should be able to produce more accurate commits than cvsps does.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: H. Peter Anvin @ 2006-03-23 6:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jan-Benedict Glaw, git
In-Reply-To: <Pine.LNX.4.64.0603221607580.26286@g5.osdl.org>
Linus Torvalds wrote:
>
> It _seems_ that the reason for that is that cvsps considers a revision
> number of 1.1.1.1 to have a "dot depth" of 0, for some really strange
> reason (it's a total special case).
>
Probably because in 99% of all cases, revision 1.1.1.1 is the result of
a "cvs import".
-hpa
^ 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