* Re: [PATCH] git-format-patch: add --output-directory long option again
From: Dennis Stosberg @ 2006-06-06 18:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwtbuthgw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> > + if (output_directory && !stdout) {
> > + if (mkdir(output_directory, 0777) < 0 && errno != EEXIST)
> > + die("Could not create directory %s",
> > + output_directory);
> > + }
> > +
>
> This code couldn't have been tested -- you meant to say
> "use_stdout" here, not "stdout".
Sorry. My version compiled and ran cleanly, but I was blinded by my
goal: I wanted the directory to be _not_ created and checked that,
but I didn't make sure, that the directory really existed in the
other case, since Git didn't produce an error.
> How about this instead?
> [...]
> + if (output_directory) {
> + if (use_stdout)
> + die("standard output, or directory, which one?");
Looks good. This piece changes behaviour; it no longer matches the
docs.
Regards,
Dennis
---
Documentation/git-format-patch.txt | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 493cac2..4ca0014 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -40,8 +40,7 @@ OPTIONS
-------
-o|--output-directory <dir>::
Use <dir> to store the resulting files, instead of the
- current working directory. This option is ignored if
- --stdout is specified.
+ current working directory.
-n|--numbered::
Name output in '[PATCH n/m]' format.
^ permalink raw reply related
* Re: [RFC] revision limiter in git-rev-list
From: Junio C Hamano @ 2006-06-06 18:29 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550606060446rc9160cbt948ceededeb22766@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> I was thinking at an extension of git-rev-list because
>
> 1) Current git-rev-list options are quite orthogonal with rev limiter.
Which means you have to think through what you want to happen
when the user uses various other existing features.
For example, let's say you want to make this work together with
path limiting. I have not thought things through, especially
around merges and fork points, but I suspect that it could be
implemented by having a new postprocessing phase:
- Get the list of commits we are interested in from the command
line.
- Teach revision.c::try_to_simplify_commit() not to drop the
commit from the simplified ancestry chain when such a list
exists.
This would probably involve disabling the code to do merge
simplification, which would make rev-list much less useful
while working in this mode.
- At the end of revision.c::limit_list(), before we compute
boundary commits perhaps, look at the resulting list and drop
single-parent commits from the ancestry chain that are not in
the "interesting" set.
When viewed this way, this thing is not a "rev limiter", but
more like "I want you keep these even if they are usually
dropped otherwise" -- "rev keeper" perhaps. That is why I said
I suspect what you want is a graph reduction and not necessarily
something that interacts with rev-list.
On the other hand, you may not mind (or you may even prefer) the
algorithm not to show commits in your "rev limiter" set if they
do not touch the specified paths. You do not have to butcher
try_to_simplify_commit() but only need the postprocessing, if
that is the case. I cannot tell which one you wanted.
By the way, I have become quite unsure about the extra inclusion
of merge and fork-point. I said:
> I think you would want to see this as the result of graph
> reduction:
>
> H
> /
> A---B---J
>
> That is, although e is a merge and c is a fork point, they do
> not bring anything interesting in the bird's eye view picture,
> and are filtered out. However, b is a point where lines of
> development leading to H and J (two of the commits the user is
> interested in) forks, and it is interesting.
But I now think what is reasonable to give might be this instead:
H
/
A---J
Often, the topic-branch workflow involves many merges between
topic and master. I will depict just one criss-cross pair here,
but in practice there will be several, mostly merging "so far
this is good" part from topic to master:
o---o---o---o---o---o---o---o "topic"
/ \ /
o---o---o---o---o---o---o---o---o "master"
When I say I am interested in viewing a reduced topology around
"topic" and "master", I could end up getting:
.---*-------*---* "topic"
/ \ /
---*-------*---*---* "master"
with many cross bridges. I am not sure why I am interested in
these cross bridges more than I am interested in the commits
that do the real work to introduce changes to the topic and
master (i.e. single parent commits). It is _interesting_ to
see, but I consider it is more of a curiosity than of a real
value in understanding what happened in the development
history.
On the other hand, if we say we are interested in seeing the
skeleton picture, I am not sure what is reasonable to draw when
your topic needed a merge from another topic because they are
somewhat related:
o---o---o---o---o---o "another topic"
/ \
/ o---o---o---X---o---o---o---o "topic"
/ / \ /
o---o---o---o---o---o---o---o---o---o "master"
Now, when you say "I am interested in seeing how topic and
master have evolved", what would you do with the merge X?
One possibility is to do this:
.-------.
/ \
/ .---*---X---*---* "topic"
/ / \ /
---Y---*-------*---*---* "master"
Between X and Y are all the interesting work that are omitted
from the bird's eye view, but nevertheless Y is a fake parent of
X. Perhaps, this is useful, but I am not so convinced.
I am afraid this is going to be the last message from me on this
topic for now, since I'd like to concentrate on getting the
"master" branch in a good shape for 1.4.0 by this weekend and
would like to have everybody do the same, and I expect to be
mostly offline next week. But I think this exchange is bringing
us closer to have a description of how the various bits in the
current rev-list are supposed to interact with this new feature,
making it a bit more concrete for us to visualize how it could
be made implementable.
There are other interactions with "existing bits" that need to
be thought through but I only gave an example and a half of path
limiter and merge/fork in this message.
Output filters (e.g. --max-count) would be easy, but I suspect
you would have even more interesting issues when you have
negative refs (^A ^B C). I currently do not have any idea how
you would do --boundary for this either.
^ permalink raw reply
* Re: New release?
From: Pavel Roskin @ 2006-06-06 18:38 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git, Linus Torvalds
In-Reply-To: <20060606164618.GC3938@reactrix.com>
On Tue, 2006-06-06 at 09:46 -0700, Nick Hengeveld wrote:
> On Tue, Jun 06, 2006 at 12:19:19PM -0400, Pavel Roskin wrote:
>
> > On Mon, 2006-06-05 at 23:02 -0700, Junio C Hamano wrote:
> > > - http-fetch fixes from Nick, which looked obviously correct.
> > > I would appreciate test reports from people who saw breakages
> > > on this one.
> >
> > I'm still getting a segfault with the current git from the "next" branch:
> >
> > $ git-clone http://www.denx.de/git/linux-2.6-denx.git
> > ...
> > got 4160b8334c53e0881cdc12c1f7d3d54fff883772
> > got 5f57f29efee48d84e235a8ff75a35e7e354227a7
> > got 681a9c73a2a321850404d4856f4738be47e17d15
> > got 29b0ddaa324e417abf153460d7d94fb67823a6ef
> > got 23e7a5c7d2c13d98524b69f54378d887e1962fc8
> > /home/proski/bin/git-clone: line 29: 27271 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
It crashed again, in a different place:
got d82e6dae84070951f625622229154cb32d3f2333
got c3e1d3e888d7b25c20d90ae4a7ecb8f5be420b98
got 2ed07112d683fa7cd1c72b0a31a7e95c6645543d
got 2721e4c8184a9a64f505686ebf7bf6e1e80ecf59
This time I was better prepared (git was compiled with -g without
optimization, the trap was commented out in git-clone, "ulimit -c" set
to unlimited), and I attached gdb to git-http-fetch.
Program received signal SIGSEGV, Segmentation fault.
0x00000000004044dc in closedown_active_slot (slot=0x656854202a200a73) at http.c:434
434 slot->in_use = 0;
(gdb) p slot
$1 = (struct active_request_slot *) 0x656854202a200a73
(gdb) p slot->in_use
Cannot access memory at address 0x656854202a200a83
(gdb) where
#0 0x00000000004044dc in closedown_active_slot (slot=0x656854202a200a73) at http.c:434
#1 0x00000000004044fa in release_active_slot (slot=0x656854202a200a73) at http.c:439
#2 0x00000000004070fc in abort_object_request (obj_req=0xdaf2b0) at http-fetch.c:1060
#3 0x00000000004071cf in fetch_object (repo=0x548f50,
sha1=0xcd4838 "ñ¿¥\025×Ûþ¥c'\210æË©\213Ö}Ûôü") at http-fetch.c:1078
#4 0x00000000004073ed in fetch (sha1=0xcd4838 "ñ¿¥\025×Ûþ¥c'\210æË©\213Ö}Ûôü")
at http-fetch.c:1126
#5 0x0000000000403126 in loop () at fetch.c:180
#6 0x000000000040336a in pull (target=0x7fff0c2e38c2 "heads/master") at fetch.c:248
#7 0x0000000000407a14 in main (argc=7, argv=0x7fff0c2e18a8) at http-fetch.c:1271
(gdb)
It's a different backtrace this time. abort_object_request() has this code:
if (obj_req->slot) {
release_active_slot(obj_req->slot);
obj_req->slot = NULL;
}
Apparently just because obj_req->slot is not NULL doesn't mean it's a
valid pointer. I'm going to use Valgrind now.
It's x86_64, FC5, Linux kernel from git.
> I just posted a fix for the compile errors. As noted there, I've done
> very little testing of the fetch/push binaries when built with
> USE_CURL_MULTI commented out.
Thank you. I'll try it too.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [REGRESSION] Interrupted clone/fetch leaves .lock files around
From: Jonas Fonseca @ 2006-06-06 18:51 UTC (permalink / raw)
To: git
Hi,
It used to be possible to continue an interrupted clone when using
cg-clone, by cding into the partial repo and run cg-fetch. However, it
seems that the recent changes in the ref locking code ends up leaving
.lock files around when interrupted.
$ cg clone http://elinks.cz/elinks.git
defaulting to local storage area
Fetching head...
Fetching objects...
...
Getting pack c0e265dab40fa34912c3ee6e02ba29686ab84a7b
which contains 16f85ec5043966c69e2142198c52e12494dcfc76
progress: 22 objects, 939754 bytes, now fetching c0e265dab40f... (657678 bytes)
cg-clone: interrupted
$ cd elinks
$ cg fetch
Recovering from a previously interrupted initial clone...
Fetching head...
Fetching objects...
error: Couldn't open lock file .git/refs/heads/origin.lock: File exists
error: Can't lock ref heads/origin
progress: 0 objects, 0 bytes
cg-fetch: objects fetch failed
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"
#include "cache.h"
@@ -214,9 +216,19 @@ static int mark_complete(const char *pat
return 0;
}
+static struct ref_lock *lock = NULL;
+
+static void remove_lockfile_on_signal(int signo)
+{
+ if (lock)
+ unlock_ref(lock);
+ lock = NULL;
+ signal(SIGINT, SIG_DFL);
+ raise(signo);
+}
+
int pull(char *target)
{
- struct ref_lock *lock = NULL;
unsigned char sha1[20];
char *msg;
int ret;
@@ -229,6 +241,7 @@ int pull(char *target)
error("Can't lock ref %s", write_ref);
return -1;
}
+ signal(SIGINT, remove_lockfile_on_signal);
}
if (!get_recover)
@@ -236,22 +249,11 @@ int pull(char *target)
if (interpret_target(target, sha1)) {
error("Could not interpret %s as something to pull", target);
- if (lock)
- unlock_ref(lock);
- return -1;
- }
- if (process(lookup_unknown_object(sha1))) {
- if (lock)
- unlock_ref(lock);
- return -1;
- }
- if (loop()) {
- if (lock)
- unlock_ref(lock);
- return -1;
- }
- if (write_ref) {
+ } else if (process(lookup_unknown_object(sha1)) || loop()) {
+ ; /* unlock */
+
+ } else if (write_ref) {
if (write_ref_log_details) {
msg = xmalloc(strlen(write_ref_log_details) + 12);
sprintf(msg, "fetch from %s", write_ref_log_details);
@@ -261,6 +263,10 @@ int pull(char *target)
if (msg)
free(msg);
return ret;
+ } else {
+ return 0;
}
- return 0;
+
+ remove_lockfile_on_signal(0);
+ return -1;
}
--
Jonas Fonseca
^ permalink raw reply related
* Re: [REGRESSION] Interrupted clone/fetch leaves .lock files around
From: Jonas Fonseca @ 2006-06-06 19:02 UTC (permalink / raw)
To: git
In-Reply-To: <20060606185148.GA15521@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote Tue, Jun 06, 2006:
> Below is my feeble attempt at a (tested) fix.
Ok, so maybe I didn't test it so well, other than continuously
interrupting the fetch. ;)
> diff --git a/fetch.c b/fetch.c
> index e040ef9..861dc60 100644
> --- a/fetch.c
> +++ b/fetch.c
> @@ -214,9 +216,19 @@ static int mark_complete(const char *pat
> return 0;
> }
>
> +static struct ref_lock *lock = NULL;
> +
> +static void remove_lockfile_on_signal(int signo)
> +{
> + if (lock)
> + unlock_ref(lock);
> + lock = NULL;
> + signal(SIGINT, SIG_DFL);
> + raise(signo);
> +}
> +
> int pull(char *target)
> {
> - struct ref_lock *lock = NULL;
> unsigned char sha1[20];
> char *msg;
> int ret;
...
> @@ -261,6 +263,10 @@ int pull(char *target)
> if (msg)
> free(msg);
> return ret;
> + } else {
> + return 0;
> }
> - return 0;
> +
> + remove_lockfile_on_signal(0);
This will end up calling raise().
> + return -1;
> }
--
Jonas Fonseca
^ permalink raw reply
* Re: [REGRESSION] Interrupted clone/fetch leaves .lock files around
From: Junio C Hamano @ 2006-06-06 19:09 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060606185148.GA15521@diku.dk>
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.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Martin Langhoff @ 2006-06-06 19:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606060813r41037467u74235f7a9386c1e0@mail.gmail.com>
On 6/7/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> Have you looked at the SVN CVS import tool? It imported Mozilla on the
> first try. If you download the source they have built about 40 test
> repositories with various errors. Those would make a good test suite
> for cvsps. http://cvs2svn.tigris.org
Haven't yet, but I'll do. I'm currently quite busy at work, but I'm
running these imports (Moz, Gentoo) and trying to address issues
arising. Will look into SVN's tool it when I have a bit more time.
What I'll probably do is steal those test cases! ;-)
> I have been working on converting the svn tool to do git commands but
> my git knowledge is limited so it has been slow going. The last stage,
> pass 8, is very similar to what the git tools do. The svn commands
> just need to be swapped for git ones.
That would be interesting. And yet, I would have to evaluate how to
transition gateways running git-cvsimport incrementally to a different
importer.
Does it do incremental imports?
> If you get git-cvsimport working I'll use it instead. Will the cvsps
> process stay small enough to run on a 32b machine? The svn tools are
Currently not, but I do hope that the moz team has access to at least
one machine with more than 32MB ;-)
With the current code, you will want a 3GB machine to run the git-cvsimport
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.
> very RAM efficient since they use an external db. Can cvsps read from
> a local copy of the repository without using a CVS server?
> We are going to have to develop some kind of incremental mechanism for
> updating the new git tree. It can take up to two days to convert the
> repository, Mozilla development can't be shut down that long for a
You don't have to. Run an initial import, and then freeze development
and run an incremental -- which will take an hour at the most. And
then your mozilla.git repo is ready and up to date.
> transition. Git will also need to mirror the CVS repository (check-in
> still going to CVS) for a long time while we convince everyone on the
> merits of switching.
That's easy -- run git-cvsimport on a cronjob.
> My imported svn version of Mozilla has a lot of performance problems.
> One of the directories has over 200,000 files in it slowing downing
> the filesystem. The repository went from 3GB CVS to 8GB svn, probably
> due to svn using 1000s of tiny files. I'll look around and see if svn
> has a pack feature like git.
At least they got a good importer ;-)
cheers,
martin
^ permalink raw reply
* Want a way to lower your payments?
From: Stella David @ 2006-06-06 20:30 UTC (permalink / raw)
To: git
Life Should be Full of Luxuries....
http://newgunforsalejoke.com/
Yet, only a handful of people can afford the finest products, the luxuries of the elite.
But, here at "Luxury Replica" we are committed to bringing you the finest products, at prices incomparably lower.
All of the top designer brands for Watches, Ties, Handbags and even Mont Blanc.
http://blessthathomepleasee.com/
The finest of products, at the lowest of prices, only a click away:
http://blessthathomepleasee.com/
Regards,
Stella David
^ permalink raw reply
* [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
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