* [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
* 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
* 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
* 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: [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
* [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: 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
* 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: [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: New release?
From: Jon Loeliger @ 2006-06-06 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Linus Torvalds
In-Reply-To: <7v3beitdct.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-06-06 at 12:15, Junio C Hamano wrote:
> I think the virtual hosting of git-daemon is very important, and
> I do not want to have a half-baked one hurriedly cobbled
> together for 1.4.0 on the server side.
Agreed.
> I do agree it is a good idea to have the client-side support in
> 1.4.0; that would work well with the current git-daemon. Since
> the extension is backward compatible, we can tell the users to
> use 1.4.0 or later clients when the daemon side is done. That
> is much nicer than telling them to use what's on "master" that
> is later than such-and-such commit.
Exactly.
> > Any chance for that? If you'd like, I work on resubmitting
> > just those bits with the connect function refactoring
> > that you outlined.
>
> I appreciate the offer very much.
No problem.
> Although I said port is
> something the server side can usually tell, I would throw in
> port there as well.
Can do.
> Any reason to spell HOST in all uppercase by the way?
I would never suggest that it came to me from
gittus in an IRC day-dream...? :-)
Consider it all lowercaseified instead.
jdl
^ permalink raw reply
* Re: New release?
From: Junio C Hamano @ 2006-06-06 17:15 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git List, Linus Torvalds
In-Reply-To: <1149610100.23938.75.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> If possible, I'd like to consider my (Linus') notion
> of the extension to the git protocol supplying the client
> hostname as part of a "standard" release like 1.4.0.
I think the virtual hosting of git-daemon is very important, and
I do not want to have a half-baked one hurriedly cobbled
together for 1.4.0 on the server side.
> We don't necessarily have to agree on how it is used yet,
> but if we can get the protocol enhancement into this
> release, I think it would make for a good "flag day"
> sort of change.
I do agree it is a good idea to have the client-side support in
1.4.0; that would work well with the current git-daemon. Since
the extension is backward compatible, we can tell the users to
use 1.4.0 or later clients when the daemon side is done. That
is much nicer than telling them to use what's on "master" that
is later than such-and-such commit.
> Specifically, I'd like to consider the portion my patch
> that passes "\0HOST=%s\0" along with the git: protocol
> connection.
>
> Any chance for that? If you'd like, I work on resubmitting
> just those bits with the connect function refactoring
> that you outlined.
I appreciate the offer very much. Although I said port is
something the server side can usually tell, I would throw in
port there as well. Maybe there is some port forwarding (or
reverse NAPT) involved in the path from the client to the
server. Any reason to spell HOST in all uppercase by the way?
And thanks for reminding me. The list of things-to-have in the
message was based on a week old "What's in", and I was about to
compose a message describing what I did not talk about in it,
because I wanted to say something about virtual hosting of
git-daemon.
^ permalink raw reply
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Junio C Hamano @ 2006-06-06 16:58 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200606061605.k56G5gHo006581@laptop11.inf.utfsm.cl>
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?
^ permalink raw reply
* Re: New release?
From: Nick Hengeveld @ 2006-06-06 16:46 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Junio C Hamano, Linus Torvalds
In-Reply-To: <1149610759.27253.9.camel@dv>
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 takes about an hour with my connection from running the command to
> the segfault. It you have any idea how to speed it up, it would be very
> helpful.
I can't offer any suggestions wrt speeding it up, but I'll do what I can
to reproduce the problem here.
> If I comment out USE_CURL_MULTI, I get compile errors in http.c and
> http-push.c.
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.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [PATCH] HTTP cleanup
From: Nick Hengeveld @ 2006-06-06 16:41 UTC (permalink / raw)
To: git
Fix broken build when USE_CURL_MULTI is not defined, as noted by Becky Bruce.
During cleanup, free header slist that was created during init, as noted
by Junio.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
I've verified that git will build with USE_CURL_MULTI commented out, but
have done very little testing of the resulting fetch/push binaries.
http-push.c | 8 ++++++++
http.c | 5 +++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/http-push.c b/http-push.c
index b1c018a..40524a8 100644
--- a/http-push.c
+++ b/http-push.c
@@ -788,6 +788,7 @@ static void finish_request(struct transf
}
}
+#ifdef USE_CURL_MULTI
void fill_active_slots(void)
{
struct transfer_request *request = request_queue_head;
@@ -821,6 +822,7 @@ void fill_active_slots(void)
slot = slot->next;
}
}
+#endif
static void get_remote_object_list(unsigned char parent);
@@ -851,8 +853,10 @@ static void add_fetch_request(struct obj
request->next = request_queue_head;
request_queue_head = request;
+#ifdef USE_CURL_MULTI
fill_active_slots();
step_active_slots();
+#endif
}
static int add_send_request(struct object *obj, struct remote_lock *lock)
@@ -889,8 +893,10 @@ static int add_send_request(struct objec
request->next = request_queue_head;
request_queue_head = request;
+#ifdef USE_CURL_MULTI
fill_active_slots();
step_active_slots();
+#endif
return 1;
}
@@ -2523,7 +2529,9 @@ int main(int argc, char **argv)
if (objects_to_send)
fprintf(stderr, " sending %d objects\n",
objects_to_send);
+#ifdef USE_CURL_MULTI
fill_active_slots();
+#endif
finish_all_active_slots();
/* Update the remote branch if all went well */
diff --git a/http.c b/http.c
index 146cf7b..a2e8e78 100644
--- a/http.c
+++ b/http.c
@@ -287,6 +287,7 @@ #ifdef USE_CURL_MULTI
#endif
curl_global_cleanup();
+ curl_slist_free_all(pragma_header);
}
struct active_request_slot *get_active_slot(void)
@@ -438,11 +439,15 @@ void release_active_slot(struct active_r
{
closedown_active_slot(slot);
if (slot->curl) {
+#ifdef USE_CURL_MULTI
curl_multi_remove_handle(curlm, slot->curl);
+#endif
curl_easy_cleanup(slot->curl);
slot->curl = NULL;
}
+#ifdef USE_CURL_MULTI
fill_active_slots();
+#endif
}
static void finish_active_slot(struct active_request_slot *slot)
--
1.3.3.g423a-dirty
^ permalink raw reply related
* Re: New release?
From: Pavel Roskin @ 2006-06-06 16:19 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Linus Torvalds
In-Reply-To: <7vodx6zus2.fsf@assigned-by-dhcp.cox.net>
Hello, Junio!
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 takes about an hour with my connection from running the command to
the segfault. It you have any idea how to speed it up, it would be very
helpful.
If I comment out USE_CURL_MULTI, I get compile errors in http.c and
http-push.c.
http.c: In function 'release_active_slot':
http.c:441: error: 'curlm' undeclared (first use in this function)
http.c:441: error: (Each undeclared identifier is reported only once
http.c:441: error: for each function it appears in.)
http.c:445: warning: implicit declaration of function
'fill_active_slots'
http-push.c: In function 'fill_active_slots':
http-push.c:801: error: 'max_requests' undeclared (first use in this
function)
http-push.c:801: error: (Each undeclared identifier is reported only
once
http-push.c:801: error: for each function it appears in.)
http-push.c:811: error: 'curlm' undeclared (first use in this function)
http-push.c: In function 'add_fetch_request':
http-push.c:855: warning: implicit declaration of function
'step_active_slots'
It may be easy to fix for somebody familiar with the code, but I don't
want to do it blindly.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: New release?
From: Jon Loeliger @ 2006-06-06 16:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Linus Torvalds
In-Reply-To: <7vodx6zus2.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-06-06 at 01:02, Junio C Hamano wrote:
> The "next" queue has been shrinking, and nothing is going to
> "maint" branch, which can mean only one thing ;-).
Junio,
If possible, I'd like to consider my (Linus') notion
of the extension to the git protocol supplying the client
hostname as part of a "standard" release like 1.4.0.
We don't necessarily have to agree on how it is used yet,
but if we can get the protocol enhancement into this
release, I think it would make for a good "flag day"
sort of change.
Specifically, I'd like to consider the portion my patch
that passes "\0HOST=%s\0" along with the git: protocol
connection.
Any chance for that? If you'd like, I work on resubmitting
just those bits with the connect function refactoring
that you outlined.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Horst von Brand @ 2006-06-06 16:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst von Brand, git
In-Reply-To: <7vpshmth3q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> writes:
>
> >> diff --git a/git-send-email.perl b/git-send-email.perl
> >> index a7a7797..700d0c3 100755
> >> --- a/git-send-email.perl
> >> +++ b/git-send-email.perl
> >> @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject,
> >>
> >> sub extract_valid_address {
> >> my $address = shift;
> >> + my $local_part_regexp = '[^<>"\s@]+';
> >> + my $domain_regexp = '[^.<>"\s@]+\.[^<>"\s@]+';
> >
> > This forces a '.' in the domain, while vonbrand@localhost is perfectly
> > reasonable. Plus it doesn't disallow adyacent '.'s. What about:
> >
> > my $domain_regexp = '[^.<>"\s@]+(\.[^<>"\s@]+)*';
> >
> > (but this is probably nitpicking...)
>
> I do not have preference either way about allowing an address
> like tld-administrator@net myself, but Email::Valid->address
> does not seem to allow it, and I just copied that behaviour for
> consistency between two alternative implementations.
Reasonable.
> I think you meant to say:
>
> > my $domain_regexp = '[^.<>"\s@]+(\.[^.<>"\s@]+)*';
>
> (i.e. exclude dot from the latter character class),
Right, my bad.
> 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). I'd just leave it plain (the performance impact shouldn't be
noticeable). I don't see any use except for $1, so the extra parenthesis
should be safe.
--
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] Cleanup git-send-email.perl:extract_valid_email
From: Junio C Hamano @ 2006-06-06 15:54 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200606061542.k56Fg9Cm006226@laptop11.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> writes:
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index a7a7797..700d0c3 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject,
>>
>> sub extract_valid_address {
>> my $address = shift;
>> + my $local_part_regexp = '[^<>"\s@]+';
>> + my $domain_regexp = '[^.<>"\s@]+\.[^<>"\s@]+';
>
> This forces a '.' in the domain, while vonbrand@localhost is perfectly
> reasonable. Plus it doesn't disallow adyacent '.'s. What about:
>
> my $domain_regexp = '[^.<>"\s@]+(\.[^<>"\s@]+)*';
>
> (but this is probably nitpicking...)
I do not have preference either way about allowing an address
like tld-administrator@net myself, but Email::Valid->address
does not seem to allow it, and I just copied that behaviour for
consistency between two alternative implementations.
I think you meant to say:
> my $domain_regexp = '[^.<>"\s@]+(\.[^.<>"\s@]+)*';
(i.e. exclude dot from the latter character class), but I am
inclined to do this instead:
my $domain_regexp = '[^.<>"\s@]+(?:\.[^.<>"\s@]+)+';
(i.e. still require at least two levels).
^ permalink raw reply
* Re: [PATCH] git-format-patch: add --output-directory long option again
From: Junio C Hamano @ 2006-06-06 15:46 UTC (permalink / raw)
To: Dennis Stosberg, Johannes Schindelin; +Cc: git
In-Reply-To: <20060606141946.G59b8a1fd@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> Additionally this fixes two minor issues:
Thanks.
> - else if (!strcmp(argv[i], "-o")) {
> - if (argc < 3)
> - die ("Which directory?");
Oops.
> + 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".
How about this instead?
-- >8 --
[PATCH] git-format-patch: add --output-directory long option again
Additionally notices and complains to an -o option without
directory or a duplicated -o option, -o and --stdout given
together. Also delays the creation of directory until all
arguments are parsed, so that the command does not leave an
empty directory behind when it exits after seeing an unrelated
invalid option.
[Originally from Dennis Stosberg but with minor fixes.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-log.c | 26 ++++++++++++++++----------
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 6612f4c..29a8851 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -103,7 +103,7 @@ static int git_format_config(const char
static FILE *realstdout = NULL;
-static char *output_directory = NULL;
+static const char *output_directory = NULL;
static void reopen_stdout(struct commit *commit, int nr, int keep_subject)
{
@@ -206,14 +206,14 @@ int cmd_format_patch(int argc, const cha
keep_subject = 1;
rev.total = -1;
}
- else if (!strcmp(argv[i], "-o")) {
- if (argc < 3)
- die ("Which directory?");
- if (mkdir(argv[i + 1], 0777) < 0 && errno != EEXIST)
- die("Could not create directory %s",
- argv[i + 1]);
- output_directory = strdup(argv[i + 1]);
+ else if (!strcmp(argv[i], "--output-directory") ||
+ !strcmp(argv[i], "-o")) {
i++;
+ if (argc <= i)
+ die("Which directory?");
+ if (output_directory)
+ die("Two output directories?");
+ output_directory = argv[i];
}
else if (!strcmp(argv[i], "--signoff") ||
!strcmp(argv[i], "-s")) {
@@ -243,6 +243,14 @@ int cmd_format_patch(int argc, const cha
if (argc > 1)
die ("unrecognized argument: %s", argv[1]);
+ if (output_directory) {
+ if (use_stdout)
+ die("standard output, or directory, which one?");
+ if (mkdir(output_directory, 0777) < 0 && errno != EEXIST)
+ die("Could not create directory %s",
+ output_directory);
+ }
+
if (rev.pending_objects && rev.pending_objects->next == NULL) {
rev.pending_objects->item->flags |= UNINTERESTING;
add_head(&rev);
@@ -293,8 +301,6 @@ int cmd_format_patch(int argc, const cha
if (!use_stdout)
fclose(stdout);
}
- if (output_directory)
- free(output_directory);
free(list);
return 0;
}
--
1.4.0.rc1-dirty
^ permalink raw reply related
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Horst von Brand @ 2006-06-06 15:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst von Brand, Ryan Anderson, Eric Wong, git
In-Reply-To: <7v1wu2zs5n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> writes:
>
> >> > # check for a local address:
> >> > - return $address if ($address =~ /^([\w\-]+)$/);
> >> > + return $address if ($address =~ /^([\w\-.]+)$/);
> >>
> >> I keep forgetting this, '+' is a valid (and useful) setup, too.
> >
> > Oops...
> >>
> >> Actually, I'm retracting my earlier ack on this. This is way too
> >> restrictive. I'd rather allow an occasional invalid email address than
> >> to reject valid ones. I generally trust git users to know what they're
> >> doing when entering email addresses[1].
> >>
> >> *, $, ^, +, = are all valid characters in the username portion (not sure
> >> about local accounts, though), and I'm sure there are more that I don't
> >> know about.
> >
> > As a general principle, I prefer to check what is legal instead of trying
> > to filter out what isn't.
> If we start doing addr-spec in RFC2822 (page 17) ourselves, we
> should rather be using Email::Valid. A permissive sanity check
> to catch obvious mistakes would be more appropriate here than
> being RFC police.
OK.
> I think something like the attached, on top of your patch, would
> be appropriate for upcoming 1.4.0.
>
> -- >8 --
> send-email: be more lenient and just catch obvious mistakes.
>
> This cleans up the pattern matching subroutine by introducing
> two variables to hold regexp to approximately match local-part
> and domain in the e-mail address. It is meant to catch obvious
> mistakes with a cheap check.
>
> The patch also moves "scalar" to force Email::Valid->address()
> to work in !wantarray environment to extract_valid_address;
> earlier it was in the caller of the subroutine, which was way
> too error prone.
Right.
> ---
> diff --git a/git-send-email.perl b/git-send-email.perl
> index a7a7797..700d0c3 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject,
>
> sub extract_valid_address {
> my $address = shift;
> + my $local_part_regexp = '[^<>"\s@]+';
> + my $domain_regexp = '[^.<>"\s@]+\.[^<>"\s@]+';
This forces a '.' in the domain, while vonbrand@localhost is perfectly
reasonable. Plus it doesn't disallow adyacent '.'s. What about:
my $domain_regexp = '[^.<>"\s@]+(\.[^<>"\s@]+)*';
(but this is probably nitpicking...)
--
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: New release?
From: Junio C Hamano @ 2006-06-06 15:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606061439500.28953@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Also, what you talk about the "lazy clone" is a lot more involved than
>> what Eric wanted to have.
>
> A little more involved. And I wanted to know what people think about this
> way to tackle shallow clones.
This truly is a lot more involved, not because "lazy clone" is
hard (which it is) but because what Eric wants to have is not to
produce a shallow clone situation. The issue is about being
able to fetch an object that is not listed as one of the refs
the server side has, and it still will result in a fully
connected repository.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-06 15:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606052255s62cda81bt62d7442beb26658a@mail.gmail.com>
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.
It probably is 796 and not a 1,000. The branch names were scrolling
across my screen and I just estimated.
> This repository has been mangled quite badly. Don't know what you guys
> did with it, but it sure isn't pretty. I'm working on getting
> git-cvsimport to get through a complete import.
The repository is close to 10 years old and it has gone through a
number of corporate reorgs. Who knows what has happened to it over
that length of time.
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
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.
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
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
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.
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.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] git-format-patch: add --output-directory long option again
From: Johannes Schindelin @ 2006-06-06 14:53 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060606141946.G59b8a1fd@leonov.stosberg.net>
Hi,
what idiot wrote that part of the code originally? ;-)
On Tue, 6 Jun 2006, Dennis Stosberg wrote:
> @@ -243,6 +241,12 @@ int cmd_format_patch(int argc, const cha
> if (argc > 1)
> die ("unrecognized argument: %s", argv[1]);
>
> + if (output_directory && !stdout) {
> + if (mkdir(output_directory, 0777) < 0 && errno != EEXIST)
> + die("Could not create directory %s",
> + output_directory);
> + }
> +
> if (rev.pending_objects && rev.pending_objects->next == NULL) {
> rev.pending_objects->item->flags |= UNINTERESTING;
> add_head(&rev);
Would it not be better to
if (output_directory && stdout)
die("What do you want: stdout or a directory?");
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-format-patch: add --output-directory long option again
From: Dennis Stosberg @ 2006-06-06 14:19 UTC (permalink / raw)
To: git
Additionally this fixes two minor issues:
(1) git-format-patch left an empty directory behind if an invalid
option was given on the command line.
(2) mkdir() was called with a NULL argument (argv[argc]), if -o was
the last option on the command line.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
builtin-log.c | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 6612f4c..0018d13 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -206,14 +206,12 @@ int cmd_format_patch(int argc, const cha
keep_subject = 1;
rev.total = -1;
}
- else if (!strcmp(argv[i], "-o")) {
- if (argc < 3)
- die ("Which directory?");
- if (mkdir(argv[i + 1], 0777) < 0 && errno != EEXIST)
- die("Could not create directory %s",
- argv[i + 1]);
- output_directory = strdup(argv[i + 1]);
+ else if (!strcmp(argv[i], "-o") ||
+ !strcmp(argv[i], "--output-directory")) {
i++;
+ if (i == argc)
+ die ("Which directory?");
+ output_directory = strdup(argv[i]);
}
else if (!strcmp(argv[i], "--signoff") ||
!strcmp(argv[i], "-s")) {
@@ -243,6 +241,12 @@ int cmd_format_patch(int argc, const cha
if (argc > 1)
die ("unrecognized argument: %s", argv[1]);
+ if (output_directory && !stdout) {
+ if (mkdir(output_directory, 0777) < 0 && errno != EEXIST)
+ die("Could not create directory %s",
+ output_directory);
+ }
+
if (rev.pending_objects && rev.pending_objects->next == NULL) {
rev.pending_objects->item->flags |= UNINTERESTING;
add_head(&rev);
--
1.3.3+git20060602-dest0
^ permalink raw reply related
* Re: New release?
From: Johannes Schindelin @ 2006-06-06 12:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virnevath.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 6 Jun 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 5 Jun 2006, Junio C Hamano wrote:
> >
> >> - letting fetch-pack ask for an arbitrary commit object the
> >> user obtained out of band (Eric W Biederman) -- waiting for
> >> updated patch. We would need a corresponding one-liner patch
> >> to upload-pack when we do this.
> >>
> >> This can wait.
> >
> > I think that this could be an important step towards a sensible "shallow
> > clone"...
>
> I did not say we are not interested in doing this ever.
I was not trying to make a case to wait with 1.4.0...
> Also, what you talk about the "lazy clone" is a lot more involved than
> what Eric wanted to have.
A little more involved. And I wanted to know what people think about this
way to tackle shallow clones.
Ciao,
Dscho
^ 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