* 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [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: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: [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: 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: Errors GITtifying GCC and Binutils
From: Timo Hirvonen @ 2006-03-23 22:36 UTC (permalink / raw)
To: git; +Cc: torvalds, seanlkml, keithp, hpa, jbglaw, git
In-Reply-To: <20060323.133120.69312511.davem@davemloft.net>
On Thu, 23 Mar 2006 13:31:20 -0800 (PST)
"David S. Miller" <davem@davemloft.net> wrote:
> 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?
Colorized "git diff", like cg-diff. Vim users can use vimpager instead
of less.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Who do I report bugs in the git source web browser thing to?
From: Rob Landley @ 2006-03-23 22:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603230856250.26286@g5.osdl.org>
On Thursday 23 March 2006 12:03 pm, Linus Torvalds wrote:
> On Thu, 23 Mar 2006, Rob Landley wrote:
> 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).
I was trying to find out when symlink support went in to gen_init_cpio.c, so
that was the only file that interested me. I forgot that the bitkeeper
history never got moved over.
Thanks,
Rob
--
Never bet against the cheap plastic solution.
^ permalink raw reply
* Re: [PATCH] doc: add clarification of existing GPLv2 license terms to manual pages
From: Sam Vilain @ 2006-03-23 23:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060323215759.GW18185@pasky.or.cz>
Petr Baudis wrote:
> 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.
I refer to this section from COPYING:
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
HOWEVER, in order to allow a migration to GPLv3 if that seems like
a good idea, I also ask that people involved with the project make
their preferences known. In particular, if you trust me to make that
decision, you might note so in your copyright message, ie something
like
This file is licensed under the GPL v2, or a later version
at the discretion of Linus.
might avoid issues. But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.
Linus Torvalds
This may become problematic if any of the copyright holders start
becoming Old Ones or otherwise not being contactable...
Sam.
^ permalink raw reply
* Re: Who do I report bugs in the git source web browser thing to?
From: sean @ 2006-03-23 23:23 UTC (permalink / raw)
To: Rob Landley; +Cc: torvalds, git
In-Reply-To: <200603231747.32166.rob@landley.net>
On Thu, 23 Mar 2006 17:47:31 -0500
Rob Landley <rob@landley.net> wrote:
> On Thursday 23 March 2006 12:03 pm, Linus Torvalds wrote:
> > On Thu, 23 Mar 2006, Rob Landley wrote:
> > 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).
>
> I was trying to find out when symlink support went in to gen_init_cpio.c, so
> that was the only file that interested me. I forgot that the bitkeeper
> history never got moved over.
>
Rob,
You might be able to find what you need in the bk history imported into
git as "Linux kernel history" by Thomas Gleixner on kernel.org:
http://kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=history;h=e7e173af42dbf37b1d946f9ee00219cb3b2bea6a;f=usr/gen_init_cpio.c
Sean
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Junio C Hamano @ 2006-03-23 23:30 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, sean, keithp, hpa, jbglaw, git
In-Reply-To: <20060323204825.GE30176@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> 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.
Export your git repository via git-cvsserver and have them use
TortoiseCVS. Such "maintain the tip and that is the only thing
what interest me" people do not even need to know the backend is
git.
^ permalink raw reply
* Re: [RFC] Silent File Mods Being Committed
From: Junio C Hamano @ 2006-03-23 23:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Loeliger, git
In-Reply-To: <20060323214710.GV18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> 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.
Likewise. If it was not obvious, I am not going to commit that
myself. If jdl or somebody cares enough, he or she can prepare
a patch to accomodate set of patches to git-core, Cogito and
StGIT (at least these three should be covered) _and_ parrot my
patch back at me. Hint, hint...
^ permalink raw reply
* Re: [RFC] Silent File Mods Being Committed
From: Junio C Hamano @ 2006-03-23 23:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Loeliger, git
In-Reply-To: <20060323214710.GV18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> 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.
Likewise. If it was not obvious, I am not going to commit that
myself. If jdl or somebody cares enough, he or she can prepare
a a set of patches to git-core, Cogito and StGIT (at least these
three should be covered) to teach them the trailing +/- letter,
_and_ parrot my patch back at me. Hint, hint...
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Junio C Hamano @ 2006-03-23 23:51 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060323210215.GH26071@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> 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.)
I do not see it as a tradeoff not to record renames. It _is_ a
feature.
On the other hand, rename detection is an eye candy, which is
sometimes useful but only sometimes. If you look at the history
of a real project, content movement across multiple files is a
norm, and content movement between two files, one of which
disappears and the other appears, is a rather narrow special
case. If you think in terms of "renames", you can only talk
about that special case, and rename detection also can only deal
with that special case.
Two good examples were discussed some time ago on the list. One
was about "where did {powerpc,pcc64}/Makefile come from?" and
the answer was "content migrated over time across multiple
commits, and you cannot really say this Makefile is renamed from
somewhere". The other was the comment by Linus on how
revision.c evolved in our project.
I am reasonably happy with how our rename detection turned out
to be, but we should keep in mind that detecting file renames is
scratching only a narrowly defined subset of the problem space.
Pickaxe was an attempt to help tracking other forms of content
movement, and it is minimally useful as a building block, but if
we really want to track content movement across file boundaries,
like Linus originally envisioned in
http://article.gmane.org/gmane.comp.version-control.git/217
we need to have a bit more Porcelain around it.
^ 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