* [PATCH][gitweb] Make it possible to retrieve HEAD plain blob
From: Petr Baudis @ 2006-06-06 20:57 UTC (permalink / raw)
To: kay.sievers; +Cc: git
Sometimes, it is useful to be able to link directly to the blob plain
version in the latest tree. This patch implements that.
Signed-off-by: Petr Baudis <pasky@suse.cz>
diff --git a/gitweb.cgi b/gitweb.cgi
index ea21fbe..abaf6ce 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -1376,7 +1376,8 @@ sub git_blob {
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$co{'tree'};hb=$hash_base")}, "tree") . "<br/>\n";
if (defined $file_name) {
print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;h=$hash;f=$file_name")}, "plain") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;hb=HEAD;f=$file_name")}, "head") . "<br/>\n";
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;hb=HEAD;f=$file_name")}, "head") .
+ " (" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;hb=HEAD;f=$file_name")}, "plain") . ")<br/>\n";
} else {
print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;h=$hash")}, "plain") . "<br/>\n";
}
@@ -1414,6 +1415,10 @@ sub git_blob_plain {
my $save_as = "$hash.txt";
if (defined $file_name) {
$save_as = $file_name;
+ if (!defined $hash) {
+ my $base = $hash_base || git_read_head($project);
+ $hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
+ }
}
print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"$save_as\"");
open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply related
* Re: [PATCH][gitweb] Make it possible to retrieve HEAD plain blob
From: Jakub Narebski @ 2006-06-06 21:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060606205737.GX10488@pasky.or.cz>
Petr Baudis wrote:
> Sometimes, it is useful to be able to link directly to the blob plain
> version in the latest tree. This patch implements that.
By the way, how to download binary file, like for example image, via gitweb?
blob_plain doesn't give correct file after Save As (in the case of image,
it is not recognized as such)...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Horst von Brand @ 2006-06-06 21:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst von Brand, git
In-Reply-To: <7vlksate4w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> > Junio C Hamano <junkio@cox.net> wrote:
> >> but I am
> >> inclined to do this instead:
> >>
> >> my $domain_regexp = '[^.<>"\s@]+(?:\.[^.<>"\s@]+)+';
> >>
> >> (i.e. still require at least two levels).
> >
> > OK, but be careful as this (?:...) is an extended regexp (needs /x on
> > match).
> Are you sure about /x?
The manual (perlop(1)) says you need /x to match extended regexps, and
(?...) is the marker for such (perlre(1)). But my perl here (5.5.8-6 on
Fedora rawhide) doesn't care...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH] HTTP cleanup
From: Junio C Hamano @ 2006-06-06 21:27 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060606164131.GB3938@reactrix.com>
Thanks. I think this is needed on top of it.
-- >8 --
[PATCH] HTTP cleanup
This ifdef's out more functions that are not used while !USE_MULTI
in http code. Also the dependency of http related objects on http.h
header file was missing in the Makefile.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 3 ++-
http-push.c | 70 ++++++++++++++++++++++++++++++-----------------------------
2 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/Makefile b/Makefile
index 004c216..f802043 100644
--- a/Makefile
+++ b/Makefile
@@ -552,7 +552,7 @@ http.o: http.c
$(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
ifdef NO_EXPAT
-http-fetch.o: http-fetch.c
+http-fetch.o: http-fetch.c http.h
$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
endif
@@ -576,6 +576,7 @@ git-ssh-push$X: rsh.o
git-imap-send$X: imap-send.o $(LIB_FILE)
+http.o http-fetch.o http-push.o: http.h
git-http-fetch$X: fetch.o http.o http-fetch.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
diff --git a/http-push.c b/http-push.c
index 40524a8..b39b36b 100644
--- a/http-push.c
+++ b/http-push.c
@@ -186,6 +186,7 @@ static void process_response(void *callb
finish_request(request);
}
+#ifdef USE_CURL_MULTI
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
void *data)
{
@@ -349,6 +350,41 @@ static void start_fetch_loose(struct tra
}
}
+static void start_mkcol(struct transfer_request *request)
+{
+ char *hex = sha1_to_hex(request->obj->sha1);
+ struct active_request_slot *slot;
+ char *posn;
+
+ request->url = xmalloc(strlen(remote->url) + 13);
+ strcpy(request->url, remote->url);
+ posn = request->url + strlen(remote->url);
+ strcpy(posn, "objects/");
+ posn += 8;
+ memcpy(posn, hex, 2);
+ posn += 2;
+ strcpy(posn, "/");
+
+ slot = get_active_slot();
+ slot->callback_func = process_response;
+ slot->callback_data = request;
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1); /* undo PUT setup */
+ curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
+ curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, request->errorstr);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_MKCOL);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
+
+ if (start_active_slot(slot)) {
+ request->slot = slot;
+ request->state = RUN_MKCOL;
+ } else {
+ request->state = ABORTED;
+ free(request->url);
+ request->url = NULL;
+ }
+}
+#endif
+
static void start_fetch_packed(struct transfer_request *request)
{
char *url;
@@ -438,40 +474,6 @@ static void start_fetch_packed(struct tr
}
}
-static void start_mkcol(struct transfer_request *request)
-{
- char *hex = sha1_to_hex(request->obj->sha1);
- struct active_request_slot *slot;
- char *posn;
-
- request->url = xmalloc(strlen(remote->url) + 13);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- strcpy(posn, "/");
-
- slot = get_active_slot();
- slot->callback_func = process_response;
- slot->callback_data = request;
- curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1); /* undo PUT setup */
- curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
- curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, request->errorstr);
- curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_MKCOL);
- curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
-
- if (start_active_slot(slot)) {
- request->slot = slot;
- request->state = RUN_MKCOL;
- } else {
- request->state = ABORTED;
- free(request->url);
- request->url = NULL;
- }
-}
-
static void start_put(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
--
1.4.0.rc1.g9c41
^ permalink raw reply related
* Re: [PATCH][gitweb] Make it possible to retrieve HEAD plain blob
From: Bertrand Jacquin @ 2006-06-06 21:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e64rhu$i7n$1@sea.gmane.org>
On 6/6/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Petr Baudis wrote:
>
> > Sometimes, it is useful to be able to link directly to the blob plain
> > version in the latest tree. This patch implements that.
>
> By the way, how to download binary file, like for example image, via gitweb?
> blob_plain doesn't give correct file after Save As (in the case of image,
> it is not recognized as such)...
This is also a gitweb fault which always define document as plain-text
instead of correct MIME.
--
# Beber : beber@gna.org
# IM : beber@jabber.fr
# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
^ permalink raw reply
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Junio C Hamano @ 2006-06-06 21:39 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200606062124.k56LOroI007738@laptop11.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> writes:
>> > OK, but be careful as this (?:...) is an extended regexp (needs /x on
>> > match).
>
>> Are you sure about /x?
>
> The manual (perlop(1)) says you need /x to match extended regexps, and
> (?...) is the marker for such (perlre(1)).
I always had the impression that eXtended in the context to talk
about /x was about ignoring whitespaces and forcing people to
write \s (or perhaps \040) when they mean a whitespace and had
nothing to do with (?...) stuff. Let me look up the fine
manual.
^ permalink raw reply
* Re: [REGRESSION] Interrupted clone/fetch leaves .lock files around
From: Junio C Hamano @ 2006-06-06 21:58 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Shawn Pearce
In-Reply-To: <7vmzcqp0cn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
>> Below is my feeble attempt at a (tested) fix.
>>
>> diff --git a/fetch.c b/fetch.c
>> index e040ef9..861dc60 100644
>> --- a/fetch.c
>> +++ b/fetch.c
>> @@ -1,3 +1,5 @@
>> +#include <signal.h>
>> +
>> #include "fetch.h"
>
> I suspect you could do something similar to what we already do
> for index updates using atexit(). Let me take a look.
Indeed it turns out that the signal work Pasky did in index.c is
exactly suitable for this. I've pushed out three patches in
"next" -- a few more eyeballs are appreciated on this one.
^ permalink raw reply
* Re: [PATCH][gitweb] Make it possible to retrieve HEAD plain blob
From: Junio C Hamano @ 2006-06-06 22:05 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git
In-Reply-To: <4fb292fa0606061431g2fcc8cdet93685b5a4977c29f@mail.gmail.com>
"Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> This is also a gitweb fault which always define document as plain-text
> instead of correct MIME.
But that is somewhat unfair to blame it for -- we do not store
what the correct mime-type is for each blob, so gitweb has to
choose between guessing and getting it wrong, or not guessing
and havign the browser deal with it. It chose the latter, which
is understandably sensible.
Having said that, I would agree it would be very nice if I can
see t/test4012.png blob in gitweb automagically ;-).
^ permalink raw reply
* Re: [PATCH][gitweb] Make it possible to retrieve HEAD plain blob
From: Bertrand Jacquin @ 2006-06-06 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtbulz32.fsf@assigned-by-dhcp.cox.net>
On 6/7/06, Junio C Hamano <junkio@cox.net> wrote:
> "Bertrand Jacquin" <beber.mailing@gmail.com> writes:
>
> > This is also a gitweb fault which always define document as plain-text
> > instead of correct MIME.
>
> But that is somewhat unfair to blame it for -- we do not store
> what the correct mime-type is for each blob, so gitweb has to
> choose between guessing and getting it wrong, or not guessing
> and havign the browser deal with it. It chose the latter, which
> is understandably sensible.
I'm ok with that. Browser can deal with if serveur do pass to it a
type=text/plain. And it's case for now :('
--
# Beber : beber@gna.org
# IM : beber@jabber.fr
# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
^ permalink raw reply
* Integrity check
From: Kenneth Johansson @ 2006-06-06 22:46 UTC (permalink / raw)
To: git
Iwas doing a git pull that ended badly and I thought that just redoing the
command may help but then git thinks everything is just fine.
After a few failed attempts I still have not find a good way to make sure
that everything is indeed correct. What is the suggested commands to do
that ?
--------
Updating from 7705a8792b0fc82fd7d4dd923724606bbfd9fb20 to
1def630a6a49dda5bc89dfbd86656293640456f0 Checking files out...
100% (6311/6311) done
Fast forward
*** glibc detected *** malloc(): memory corruption: 0x0a703e80 ***
/home/ken/bin/git-merge: line 56: 14121 Aborted
git-diff-tree -p --stat --summary -M "$head" "$1"
>git pull
* refs/heads/origin: same as branch 'master' of
/delta/kernel/git/linux-2.6/ Already up-to-date.
[
^ permalink raw reply
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Horst von Brand @ 2006-06-06 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst von Brand, git
In-Reply-To: <7vlksanev9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> >> > OK, but be careful as this (?:...) is an extended regexp (needs /x on
> >> > match).
> >
> >> Are you sure about /x?
> >
> > The manual (perlop(1)) says you need /x to match extended regexps, and
> > (?...) is the marker for such (perlre(1)).
> I always had the impression that eXtended in the context to talk
> about /x was about ignoring whitespaces and forcing people to
> write \s (or perhaps \040) when they mean a whitespace and had
> nothing to do with (?...) stuff. Let me look up the fine
> manual.
You might be right... and it even sounds sensible; but both (?...) stuff
and the ignoring of space is described as extended here.
Note that \s is a space character (' ', '\t', ...), which is not the same
as \040 (and that one assumes ASCII...).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Integrity check
From: Linus Torvalds @ 2006-06-06 22:53 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: git
In-Reply-To: <pan.2006.06.06.22.46.26.518589@canit.se>
On Wed, 7 Jun 2006, Kenneth Johansson wrote:
>
> Iwas doing a git pull that ended badly and I thought that just redoing the
> command may help but then git thinks everything is just fine.
What happened is that your first pull actually worked fine, but the final
"git-diff-tree" that shows what the pull actually _did_ ended up
SIGSEGV'ing.
Subsequent pulls won't SIGSEGV, because they dont' have anything to do any
more: your state is fine.
I think the SIGSEGV was due to the problem (that Junio already fixed) with
a corrupted heap due to the "diffstat" doing bad things for renames.
So you probably do want to update your git version, but I don't think
anything bad actually ever happened, apart from the (a) scare and (b) lack
of diffstat output after the pull.
> After a few failed attempts I still have not find a good way to make sure
> that everything is indeed correct. What is the suggested commands to do
> that ?
In the future, just do "git fsck-objects --full" if you're nervous. That
will do a full integrity check.
Linus
^ permalink raw reply
* Re: Integrity check
From: Linus Torvalds @ 2006-06-06 22:56 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606061550100.5498@g5.osdl.org>
On Tue, 6 Jun 2006, Linus Torvalds wrote:
>
> In the future, just do "git fsck-objects --full" if you're nervous. That
> will do a full integrity check.
Btw, this can output some scary-sounding "unreachable commit xxxxxx"
messages or similar, without that actually necessarily being a problem at
all. Unreachable objects are normal if you've deleted branches, for
example, or if you rebase (or your upstream rebases, like the "pu" branch
in the git archive).
So if you just see a few unreachable objects, doing a "git prune" will get
rid of them, and they aren't normally any sign of actual trouble.
Linus
^ permalink raw reply
* [PATCH] builtin-grep: pass ignore case option to external grep
From: Robert Fitzsimons @ 2006-06-06 23:15 UTC (permalink / raw)
To: git
Don't just read the --ignore-case/-i option, pass the flag on to the
external grep program.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
builtin-grep.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index acc4eea..5fac570 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -459,6 +459,8 @@ static int external_grep(struct grep_opt
push_arg("-n");
if (opt->regflags & REG_EXTENDED)
push_arg("-E");
+ if (opt->regflags & REG_ICASE)
+ push_arg("-i");
if (opt->word_regexp)
push_arg("-w");
if (opt->name_only)
--
1.3.3.g16a4-dirty
^ permalink raw reply related
* Re: [PATCH] builtin-grep: pass ignore case option to external grep
From: Linus Torvalds @ 2006-06-06 23:27 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: git
In-Reply-To: <20060606231516.GA18405@localhost>
On Tue, 6 Jun 2006, Robert Fitzsimons wrote:
>
> Don't just read the --ignore-case/-i option, pass the flag on to the
> external grep program.
Oops. How did we miss that one ;)
Embarrassing.
Linus
^ permalink raw reply
* [PATCH/RFC] "git --less cmd" to page anywhere
From: Junio C Hamano @ 2006-06-06 23:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606041621010.5498@g5.osdl.org>
This allows you to say:
git --less diff v2.6.16-rc5..
to pipe the output of any git command to your pager.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 4 Jun 2006, Petr Baudis wrote:
>>
>> And I forgot to mention that it also adds the interactivity test
>> requested by Janek - aliases are now interpreted only when stdout is a
>> tty.
>
> I don't think that's a good test.
>
> The fact is, I do
>
> git diff | less -S
>
> all the time,...
This is not a serious patch, since I suspect it would obviously
not make much sense to say "git --less commit" or somesuch,
but it was fun to do.
git.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index bc463c9..c52da8c 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h"
#include "builtin.h"
@@ -162,6 +163,10 @@ int main(int argc, const char **argv, ch
puts(git_exec_path());
exit(0);
}
+ if (!strcmp(cmd, "less")) {
+ setup_pager();
+ continue;
+ }
cmd_usage(0, NULL, NULL);
}
argv[0] = cmd;
^ permalink raw reply related
* Re: [PATCH/RFC] "git --less cmd" to page anywhere
From: Linus Torvalds @ 2006-06-07 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodx5n8en.fsf_-_@assigned-by-dhcp.cox.net>
On Tue, 6 Jun 2006, Junio C Hamano wrote:
>
> This allows you to say:
>
> git --less diff v2.6.16-rc5..
I've seriously considered something like that, although you chose a pretty
strange - and long - flag.
I was thinking something like "git -p log -p" (the first "-p" is for
"paginate" - think "dir/p" in old DOS times, but we could claim it is for
"pager" so that people don't laugh at us)
Linus
^ permalink raw reply
* Re: [PATCH/RFC] "git --less cmd" to page anywhere
From: Petr Baudis @ 2006-06-07 0:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606061703380.5498@g5.osdl.org>
Dear diary, on Wed, Jun 07, 2006 at 02:05:59AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 6 Jun 2006, Junio C Hamano wrote:
> >
> > This allows you to say:
> >
> > git --less diff v2.6.16-rc5..
>
> I've seriously considered something like that, although you chose a pretty
> strange - and long - flag.
>
> I was thinking something like "git -p log -p" (the first "-p" is for
> "paginate" - think "dir/p" in old DOS times, but we could claim it is for
> "pager" so that people don't laugh at us)
Actually, you made a case in the misty past that cg-log should just
stuff things through a pager by default and I ended up finding that
extremely convenient - what is the reason git log does not do the same?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Keith Packard @ 2006-06-07 0:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: keithp, Jon Smirl, git
In-Reply-To: <46a038f90606061257v569aefackc4920a20f2970b0f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
On Wed, 2006-06-07 at 07:57 +1200, Martin Langhoff wrote:
> git-cvsimport has a memory leak that I've been chasing for a while and
> I'll eventually fix, so it should fit in 32MB comfortably. cvsps is
> memory bound, and will probably take quite a bit of work to fix that.
> However, I suspect we can make it a lot more efficient.
Yeah, parsecvs is a memory pig as well -- it builds a giant in-memory
representation of the entire project history using flat lists of files
for every revision, just like git used to do. Fixing that should make it
run in small amounts of memory; it only needs 40 bytes per file revision
for the raw data as it converts the cvs files to git objects as it reads
them, saving only the hash value in memory.
Not relying on cvsps has been a huge feature though; cvsps loses a
tremendous amount of data, along with making several gross and difficult
to fix errors in project history from several of my repositories.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] "git --less cmd" to page anywhere
From: Linus Torvalds @ 2006-06-07 0:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060607000816.GY10488@pasky.or.cz>
On Wed, 7 Jun 2006, Petr Baudis wrote:
>
> Actually, you made a case in the misty past that cg-log should just
> stuff things through a pager by default and I ended up finding that
> extremely convenient - what is the reason git log does not do the same?
"git log" does, "git diff" does not (and yeah, I just chose a bad example,
I meant "git -p diff -p")
For "git diff", pagination by default is definitely not the right thing to
do, but it's something you often end up wanting.
Linus
^ permalink raw reply
* [PATCH] Support for configurable git command aliases (v3)
From: Petr Baudis @ 2006-06-07 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch adds support for configurable aliases for git commands -
"alias.WHATEVER = which ever" will kick in when you do "git WHATEVER"
and substitute WHATEVER with "which ever" (splitted to arguments at
whitespaces).
The second version does all the work in handle_aliases() which was
inspired by Johannes Schindelin's patch.
The third version does not expand aliases when called as 'git-something'
or when the $GIT_NO_ALIASES environment variable is set; that is now
done in git-sh-setup.sh. The documentation has been slightly expanded.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/config.txt | 12 +++++++++
Documentation/git.txt | 3 ++
git-sh-setup.sh | 2 +
git.c | 64 ++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c861c6c..071ff4e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -91,6 +91,18 @@ core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
and might match multiple refs in the .git/refs/ tree. True by default.
+alias.*::
+ Command aliases for the gitlink:git[1] command wrapper - e.g.
+ after defining "alias.last = cat-file commit HEAD", the invocation
+ "git last" is equivalent to "git cat-file commit HEAD". You can
+ override even existing command names with aliases (you can use that
+ to define some default set of parameters for some command). However,
+ there is only a single level of alias expansion - the alias definition
+ is not searched for aliases anymore. Alias checking is disabled when
+ the "$GIT_NO_ALIASES" environment variable is set - you should
+ definitely do that if you call commands by the 'git' wrapper in your
+ scripts.
+
apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 24ca55d..e474bdf 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -21,6 +21,9 @@ link:everyday.html[Everyday Git] for a u
"man git-commandname" for documentation of each command. CVS users may
also want to read link:cvs-migration.html[CVS migration].
+The COMMAND is either a name of a Git command (see below) or an alias
+as defined in the configuration file (see gitlink:git-repo-config[1]).
+
OPTIONS
-------
--version::
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index d15747f..c56ae8c 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -49,3 +49,5 @@ then
else
GIT_DIR=$(git-rev-parse --git-dir) || exit
fi
+
+export GIT_NO_ALIASES=1
diff --git a/git.c b/git.c
index bc463c9..b85dafa 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h" /* setup_git_directory_gently() */
#include "builtin.h"
@@ -88,13 +89,66 @@ static void handle_internal_command(int
}
}
+static const char *cmd;
+static char *cmdalias;
+
+int git_alias_config(const char *var, const char *value)
+{
+ if (strncmp(var, "alias.", 6))
+ return 0;
+ var += /* strlen("alias.") */ 6;
+ if (!strcmp(var, cmd))
+ cmdalias = strdup(value);
+ return 0;
+}
+
+void handle_alias(int *argc, const char ***argv)
+{
+ /* XXX: We do a redundant git directory detection. */
+ int nongit = 0;
+ const char *subdir;
+ char *env = getenv("GIT_NO_ALIASES");
+
+ if (!env || !*env)
+ return;
+
+ subdir = setup_git_directory_gently(&nongit);
+ if (!nongit) {
+ git_config(git_alias_config);
+ if (cmdalias) {
+ /* More than the worst case: */
+ const char **argv2 = malloc((strlen(cmdalias) + *argc) * sizeof(char*));
+ int argc2 = 0, i = 1;
+
+ while (cmdalias && *cmdalias) {
+ argv2[argc2++] = strsep(&cmdalias, " \t");
+ if (cmdalias)
+ while (*cmdalias == ' ' || *cmdalias == '\t')
+ cmdalias++;
+ }
+ while (i < *argc) {
+ argv2[argc2++] = (*argv)[i++];
+ }
+ argv2[argc2] = NULL;
+ *argv = argv2;
+ *argc = argc2;
+ }
+ }
+
+ /* Go back so that the commands start with clean table */
+ if (subdir)
+ chdir(subdir);
+}
+
+
int main(int argc, const char **argv, char **envp)
{
- const char *cmd = argv[0];
- char *slash = strrchr(cmd, '/');
+ char *slash = strrchr(argv[0], '/');
char git_command[PATH_MAX + 1];
const char *exec_path = NULL;
+ cmd = argv[0];
+
/*
* Take the basename of argv[0] as the command
* name, and the dirname as the default exec_path
@@ -117,6 +171,10 @@ int main(int argc, const char **argv, ch
*
* So we just directly call the internal command handler, and
* die if that one cannot handle it.
+ *
+ * We also do not evaluate aliases in this case since git-log
+ * should never expand to something unpredictable (that is
+ * important e.g. for scripts).
*/
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
@@ -178,7 +236,7 @@ int main(int argc, const char **argv, ch
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
- /* See if it's an internal command */
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
/* .. then try the external ones */
^ permalink raw reply related
* Re: [PATCH] Support for configurable git command aliases (v3)
From: Petr Baudis @ 2006-06-07 0:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060607001638.5175.77792.stgit@machine.or.cz>
Dear diary, on Wed, Jun 07, 2006 at 02:16:38AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> This patch adds support for configurable aliases for git commands -
> "alias.WHATEVER = which ever" will kick in when you do "git WHATEVER"
> and substitute WHATEVER with "which ever" (splitted to arguments at
> whitespaces).
>
> The second version does all the work in handle_aliases() which was
> inspired by Johannes Schindelin's patch.
>
> The third version does not expand aliases when called as 'git-something'
> or when the $GIT_NO_ALIASES environment variable is set; that is now
> done in git-sh-setup.sh. The documentation has been slightly expanded.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
So, I chose the approach suggested by Linus, but I do not have a strong
preference and if Junio still wants, we can rather just disallow aliases
with the same name as builtins - I just think that it *might* be
practical to add some default options to the commands without relearning
your typing habits.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] Support for configurable git command aliases (v3)
From: Junio C Hamano @ 2006-06-07 0:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060607001638.5175.77792.stgit@machine.or.cz>
I've already swallowed Johannes's patch that also takes good
parts from your patch (most importantly, the part to call
setup_git_directory_gently() so that things can work from a
subdirectory and still find the config) in "next", and I am
hoping to push it out by end of (my) tomorrow. So I'd
appreciate any improvements (including docs perhaps) on top of
that instead.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-07 0:40 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <9e4733910606060813r41037467u74235f7a9386c1e0@mail.gmail.com>
On 6/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 6/6/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > On 6/3/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 6/1/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > With the attached patch you can parse the entire Mozilla tree. The
> > > > tree has over 100,000 files in it and about 300 branches.
> > >
> > > I was a little low with these counts, more like 110,000 files and some
> > > parts of the tree have 1,000 branches. Total tree size is 3GB.
> >
> > I don't think it really has that many branches. If I am to believe
> > cvsps (which took 3GB to walk the history), it has some branches with
> > recursive loops in their ancestry (MANG_MATH_BRANCH and
> > SpiderMonkey140_BRANCH have eachother as ancestors!?), 197969 commits
> > and 796 branches.
My full import to svn just finished after a day and a half.
Here are the stats:
cvs2svn Statistics:
------------------
Total CVS Files: 99851
Total CVS Revisions: 948580
Total Unique Tags: 1505
Total Unique Branches: 1577
CVS Repos Size in KB: 2725843
Total SVN Commits: 205787
First Revision Date: Fri Mar 27 21:13:08 1998
Last Revision Date: Tue May 30 19:28:10 2006
------------------
Timings:
------------------
pass 1: 3602 seconds
pass 2: 227 seconds
pass 3: 66 seconds
pass 4: 1070 seconds
pass 8:124650 seconds
total: 124650 seconds
[jonsmirl@jonsmirl ~]$
[jonsmirl@jonsmirl svn]$ du -h
4.0K ./svntest/dav
12K ./svntest/locks
40K ./svntest/hooks
16K ./svntest/conf
7.4G ./svntest/db/revs
808M ./svntest/db/revprops
4.0K ./svntest/db/transactions
8.2G ./svntest/db
8.2G ./svntest
8.2G .
[jonsmirl@jonsmirl svn]$ find | wc
411607 411607 10891057
There are two directories that each contain about 205k files. 205K
files in a single directory is causing svn problems on Ext3.
Bottom line, cvs2svn import tool works quite well. Highest memory
consumption I saw was 100MB and it used 6GB of extra disk while
running plus space need by svn.
I don't know quite enough about git yet to replace the svn commands it
uses with git equivalents but if that were done I think most of the
cvs import problems would be solved. Obviously the svn team has put a
great deal of work into this program.
I don't think replacing the svn commands is very hard, I just haven't
figured out the right way to build branches with low-level git yet and
I don't know Python. I'll bet someone already familiar with git and
cvs import could convert it in a couple of hours.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Integrity check
From: Dave Jones @ 2006-06-07 0:58 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: git
In-Reply-To: <pan.2006.06.06.22.46.26.518589@canit.se>
On Wed, Jun 07, 2006 at 12:46:27AM +0200, Kenneth Johansson wrote:
> *** glibc detected *** malloc(): memory corruption: 0x0a703e80 ***
The last time I saw one of these in git, it turned out to be
due to a bug in glibc. If you're using Fedora/RHEL, there are
updates available that fix this problem.
Dave
--
http://www.codemonkey.org.uk
^ 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