* Re: [RFC] gitweb wishlist and TODO list
From: Martin Langhoff @ 2006-06-20 19:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79921$u0e$1@sea.gmane.org>
On 6/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
> I am planning on copying features from xmms2's gitweb version
> to git's gitweb, and introducing new ones.
Cool!
> * Storing site-wide gitweb configuration in separate gitweb.conf file.
> Needs GIT_CONFIG patch. Not implemented yet.
>
> Bootstrapping: gitweb would need location of configuration file.
> Has to be changed in gitweb.cgi itself. Additionally gitexecdir or
> git in PATH is needed to be able to run git-repo-config to read config;
> the solution might be home-grown "parser" to find gitexecdir only.
>
> Both could be set from Makefile at install stage.
There's been some discussion about reading GIT_CONFIG from %ENV (but
defaulting to the repo config). If GIT_CONFIG is set, I think we can
trick git-repo-config to parse it for us.
Now, I suspect we'll want to read _both_ the per-repo config and
GIT_CONFIG, which is likely to be /etc/gitweb.conf or similar.
> * Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
> base_url, which need not to be set as there is sane default: use base
> of gitweb URL.
>
> Is it useful to allow repository configuration to override it?
I think so, as mentioned above.
> * Add (of course optional, like blame support) snapshot support. There are
> at least two different implementations. I'd prefer to do without second
> CGI script, but perhaps this is better from the performance point of view.
> gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?
I intend to post a patch that adds snapshot support in Perl, in the
main code. Just need to make it optional ;-)
> * Code highlighting for plain view for blobs. gitweb-xmms2 did that using
> GNU highlight program and some embedded configuration (filename regexp to
> syntax used). More generic: run some post-processing. Configurable
> globally (perhaps separate "syntax type" filename or file magic mapping),
> and enabled per repository (default off).
Yep, probably a generic filter facility is better...
> * gitweb-xmms2 has something called committags support: it means that
> 'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
> bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
> sha1-ids into references. Probably needs some extra configuration file,
> and some per repository configuration. Of course we want to support not
> only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
> for marking bugs therein.
That would be great.
...
> Which of those should be implemented first?
I like the order the list has... but it's up to you.
> Any further ideas for other useful features?
Now what I think would rock too is something similar to gitk's "nearby
tags" feature. When reading a commit, it lists the heads and tags that
this commit is part of. It's very useful. Now I'll have to read up on
how gitk does it.
And, as you mention in your other post, mod_perl support. And a bit of
speed. Gitweb rght now is really really slow.
cheers,
martin
^ permalink raw reply
* Re: packs and trees
From: Martin Langhoff @ 2006-06-20 19:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606201102410.3377@localhost.localdomain>
On 6/21/06, Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 20 Jun 2006, Martin Langhoff wrote:
>
> > On 6/20/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > The plan is to modify rcs2git from parsecvs to create all of the git
> > > objects for the tree.
> >
> > Sounds like a good plan. Have you seen recent discussions about it
> > being impossible to repack usefully when you don't have trees (and
> > resulting performance problems on ext3).
>
> What do you mean?
I was thinking of the "repacking disconnected objects" thread, but now
I see it did have a solution in listing all the objects and paths. I
take that back.
If you are asking about the ext3 performance problems, I think Linus
discussed that a while ago, why unpacked repos are slow (in addition
to huge), and there were some suggestions of using hashed directory
indexes.
cheers,
martin
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Junio C Hamano @ 2006-06-20 19:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79921$u0e$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I am planning on copying features from xmms2's gitweb version
> to git's gitweb, and introducing new ones.
>
> Which of those should be implemented first?
Clean-ups and obvious fixes without introducing new features
first please.
> * Add (of course optional, like blame support) snapshot support. There are
> at least two different implementations. I'd prefer to do without second
> CGI script, but perhaps this is better from the performance point of view.
> gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?
Isn't it just the matter of spawning git-tar-tree?
> * gitweb-xmms2 has something called committags support: it means that
> 'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
> bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
> sha1-ids into references. Probably needs some extra configuration file,
> and some per repository configuration. Of course we want to support not
> only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
> for marking bugs therein.
Yes, I found this quite nice.
BTW, are you in touch with xmms2 folks?
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-06-20 19:56 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90606201233p6283febbn9a46e36c3a666903@mail.gmail.com>
Martin Langhoff wrote:
> On 6/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> * Add (of course optional, like blame support) snapshot support. There are
>> at least two different implementations. I'd prefer to do without second
>> CGI script, but perhaps this is better from the performance point of view.
>> gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?
>
> I intend to post a patch that adds snapshot support in Perl, in the
> main code. Just need to make it optional ;-)
Check http://marc.theaimsgroup.com/?l=git&m=111909432415478&w=2 for
in the main code snapshot implementation.
http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
http://www.liacs.nl/~sverdool/gitweb.git
Would separate snapshot CGI script make it work faster?
>> Any further ideas for other useful features?
>
> Now what I think would rock too is something similar to gitk's "nearby
> tags" feature. When reading a commit, it lists the heads and tags that
> this commit is part of. It's very useful. Now I'll have to read up on
> how gitk does it.
If I remember correctly, it was done in the background, and it was done
at least partially _in_ gitk (Tcl/Tk).
> And, as you mention in your other post, mod_perl support. And a bit of
> speed. Gitweb right now is really really slow.
Perhaps mod_cache would help. Especially if cache can be configured to
look only at the hash part, plus formatting (normal, plain/raw, blame,
search match highlighting).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Petr Baudis @ 2006-06-20 20:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79921$u0e$1@sea.gmane.org>
Dear diary, on Tue, Jun 20, 2006 at 06:51:18PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> * Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
> base_url, which need not to be set as there is sane default: use base
> of gitweb URL.
>
> Is it useful to allow repository configuration to override it?
Certainly. E.g. http://pasky.or.cz/gitweb.cgi hosts some random projects
but generally they are to be fetched from totally different locations.
> * Refactor dispatch from if...elsif...else construction
> to using 'name' => \&sub hash.
In other words, you say the result of the IRC discussion we had about
symbol lookups and evals turned out really scary? ;-)
> * gitweb-xmms2 has something called committags support: it means that
> 'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
> bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
> sha1-ids into references. Probably needs some extra configuration file,
> and some per repository configuration. Of course we want to support not
> only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
> for marking bugs therein.
For Bugzilla, just /\bbug (\d+)/i is frequently used so many people are
probably used to it while it feels natural and doesn't make you tumble
over it when reading the message.
For these things it's simplest to give the user ability to specify some
regexp substitutions to be applied on commit messages.
About sha1 turned to references, I don't think that's practical until
you will have some way of finding out whether a given sha1 is a valid
object reference without Theta(n) forks.
--
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: packs and trees
From: Nicolas Pitre @ 2006-06-20 20:51 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jon Smirl, git
In-Reply-To: <46a038f90606201241x3dec242dicde245a24c3ab9ab@mail.gmail.com>
On Wed, 21 Jun 2006, Martin Langhoff wrote:
> On 6/21/06, Nicolas Pitre <nico@cam.org> wrote:
> > On Tue, 20 Jun 2006, Martin Langhoff wrote:
> >
> > > On 6/20/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > The plan is to modify rcs2git from parsecvs to create all of the git
> > > > objects for the tree.
> > >
> > > Sounds like a good plan. Have you seen recent discussions about it
> > > being impossible to repack usefully when you don't have trees (and
> > > resulting performance problems on ext3).
> >
> > What do you mean?
>
> I was thinking of the "repacking disconnected objects" thread, but now
> I see it did have a solution in listing all the objects and paths. I
> take that back.
OK.
Nicolas
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-06-20 20:59 UTC (permalink / raw)
To: git
In-Reply-To: <20060620201035.GT2609@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Tue, Jun 20, 2006 at 06:51:18PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> * Refactor dispatch from if...elsif...else construction
>> to using 'name' => \&sub hash.
>
> In other words, you say the result of the IRC discussion we had about
> symbol lookups and evals turned out really scary? ;-)
First, we need arrays (ordering!) of sets of possible actions for navbar,
so we will have list of all possible actions.
Besides, simple test
[...]
sub dispatch {
dispatch_ifelse(@_);
#dispatch_hash(@_);
#dispatch_callname(@_);
#dispatch_anonsub(@_);
}
sub test_dispatch_all {
dispatch(undef);
dispatch("summary");
[...]
dispatch("tag");
dispatch("unknown");
dispatch("tag();injected();");
}
test_dispatch_all() foreach (1..10000);
run with '$ time ./test.pl > /dev/null' has shown that (suprise, suprise!)
that hash is fastest, then if...elsif...else variant, then
my $sub = \&{"git_$action"}; eval { &$sub() };
and last, much much worse is eval "..." version.
Of course test leaves something to be desired...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Martin Langhoff @ 2006-06-20 21:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79jtd$51j$1@sea.gmane.org>
On 6/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
> > I intend to post a patch that adds snapshot support in Perl, in the
> > main code. Just need to make it optional ;-)
>
> Check http://marc.theaimsgroup.com/?l=git&m=111909432415478&w=2 for
> in the main code snapshot implementation.
>
> http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
> http://www.liacs.nl/~sverdool/gitweb.git
>
> Would separate snapshot CGI script make it work faster?
I was thinking about that same one, we found (and fixed) a bug or two
on top of that so my plan is to rebase it on top of the gitweb on next
;-)
> >> Any further ideas for other useful features?
> >
> > Now what I think would rock too is something similar to gitk's "nearby
> > tags" feature. When reading a commit, it lists the heads and tags that
> > this commit is part of. It's very useful. Now I'll have to read up on
> > how gitk does it.
>
> If I remember correctly, it was done in the background, and it was done
> at least partially _in_ gitk (Tcl/Tk).
I suspect it is doing a whole lot of git-merge-base invocations, which
are rather costly. I don't know of any cheaper way to ask that
question.
> > And, as you mention in your other post, mod_perl support. And a bit of
> > speed. Gitweb right now is really really slow.
>
> Perhaps mod_cache would help. Especially if cache can be configured to
> look only at the hash part, plus formatting (normal, plain/raw, blame,
> search match highlighting).
Right, some URLs are guaranteed to be static (those blob views), so it
can just cache on the full URL, for ever and ever. The other ones...
well, we just make sure we don't do anything too expensive there ;-)
martin
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Petr Baudis @ 2006-06-20 21:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79921$u0e$1@sea.gmane.org>
> Any further ideas for other useful features?
By the way, it would definitely make me feel better about gitweb
security-wise if it would run with taints checks on - they are very good
idea.
--
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] Log peer address when git-daemon called from inetd
From: Junio C Hamano @ 2006-06-20 21:31 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1150814294.17609.68.camel@hades.cambridge.redhat.com>
Thanks.
^ permalink raw reply
* [PATCH 2/2 (resend)] gitweb: add '/' to the end of filename in page title for trees
From: Jakub Narebski @ 2006-06-20 21:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <11508395812645-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski
---
gitweb/gitweb.cgi | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
d17c119d32ae4c5dd50976ea6a255d2bcbe480ed
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 1e1a044..42f3296 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -263,6 +263,9 @@ sub git_header_html {
$title .= "/$action";
if (defined $file_name) {
$title .= " - $file_name";
+ if ($action eq "tree" && $file_name !~ m|/$|) {
+ $title .= "/";
+ }
}
}
}
--
1.3.0
^ permalink raw reply related
* [PATCH 1/2 (resend)] gitweb: Add filename to page title if it is set
From: Jakub Narebski @ 2006-06-20 21:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
Signed-off-by: Jakub Narebski
---
gitweb/gitweb.cgi | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
a54751bb328072baed5446bdc4076f1e00002737
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 12d5271..1e1a044 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -260,7 +260,10 @@ sub git_header_html {
if (defined $project) {
$title .= " - $project";
if (defined $action) {
+ if (defined $file_name) {
+ $title .= " - $file_name";
+ }
}
}
print $cgi->header(-type=>'text/html', -charset => 'utf-8', -status=> $status, -expires => $expires);
--
1.3.0
^ permalink raw reply related
* [PATCH] gitweb.cgi: whitespace cleanup
From: Jakub Narebski @ 2006-06-20 21:52 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
Signed-off-by: Jakub Narebski
---
gitweb/gitweb.cgi | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)
370a5cd4c8151c10809f03f0e32c7ef3767d4bb1
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 42f3296..11cc71f 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -17,33 +17,33 @@ use Fcntl ':mode';
binmode STDOUT, ':utf8';
my $cgi = new CGI;
-my $version = "267";
-my $my_url = $cgi->url();
-my $my_uri = $cgi->url(-absolute => 1);
-my $rss_link = "";
+my $version = "267";
+my $my_url = $cgi->url();
+my $my_uri = $cgi->url(-absolute => 1);
+my $rss_link = "";
# absolute fs-path which will be prepended to the project path
-#my $projectroot = "/pub/scm";
-my $projectroot = "/home/kay/public_html/pub/scm";
+#my $projectroot = "/pub/scm";
+my $projectroot = "/home/kay/public_html/pub/scm";
# location of the git-core binaries
-my $gitbin = "/usr/bin";
+my $gitbin = "/usr/bin";
# location for temporary files needed for diffs
-my $git_temp = "/tmp/gitweb";
+my $git_temp = "/tmp/gitweb";
# target of the home link on top of all pages
-my $home_link = $my_uri;
+my $home_link = $my_uri;
# html text to include at home page
-my $home_text = "indextext.html";
+my $home_text = "indextext.html";
# URI of default stylesheet
-my $stylesheet = "gitweb.css";
+my $stylesheet = "gitweb.css";
# source of projects list
-#my $projects_list = $projectroot;
-my $projects_list = "index/index.aux";
+#my $projects_list = $projectroot;
+my $projects_list = "index/index.aux";
# default blob_plain mimetype and default charset for text/plain blob
my $default_blob_plain_mimetype = 'text/plain';
@@ -51,7 +51,7 @@ my $default_text_plain_charset = undef;
# file to use for guessing MIME types before trying /etc/mime.types
# (relative to the current git repository)
-my $mimetypes_file = undef;
+my $mimetypes_file = undef;
# input validation and dispatch
--
1.3.0
^ permalink raw reply related
* Re: [RFC] gitweb wishlist and TODO list
From: Thomas Glanzmann @ 2006-06-20 21:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Michael Gernoth
In-Reply-To: <e79921$u0e$1@sea.gmane.org>
Hello,
> Any further ideas for other useful features?
a friend of mine was yesterday complained to me about not be able to see
which file was last touched in a given directory like it is possible
with viewcvs[1]. I told him that he should just call 'git whatchanged
-p'. And he answered back 'downloading 128Mbytes' for a few bytes
of history? I told him to address this list with his feature request, but
he didn't do so far. So I use this opportunity. Maybe something else
would be much more handier: Use gitweb to request the log and shortlog
of a directory tree, like git-whatchanged arch/i386 does for example.
Maybe it is already possible and I missed it?
Thomas
[1] viewcvs prints the last touch of a a file in a directory and you can
tell it to sort after the date criteria:
http://faumachine.informatik.uni-erlangen.de/cgi-bin/viewcvs.cgi/mutt/?sortby=date#dirlist
^ permalink raw reply
* Odd behavior with git and cairo-devel repo
From: Art Haas @ 2006-06-21 1:00 UTC (permalink / raw)
To: git
Hi.
I've been seeing some odd errors with git when it is dealing with
the Cairo graphics library repo. The errors include git failing
a 'fsck-objects' with a 'Floating point exception' error message
and 'git prune' mangling the repo.
A fresh cloning of the repo is needed to see the FPE error. The
repo is about 13M in size, btw.
$ git clone git://git.cairographics.org/git/cairo cairo
[ ... git clones the repo without problem ... ]
$ cd cairo
$ git fsck-objects
Floating point exception
$
The strace of this shows that things bomb after the '.git/index' file is
read. Here's the tail end of the strace output ...
close(3) = 0
open(".git/index", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=51472, ...}) = 0
mmap2(NULL, 51472, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0xb7f4b000
close(3) = 0
--- SIGFPE (Floating point exception) @ 0 (0) ---
+++ killed by SIGFPE +++
Now, if the repo is added to and you 'git pull' to update your copy,
the 'git fsck-objects' command completes without error.
As for the problem where 'git prune' mangles the local copy, it would
happen after a 'git fsck-objects' run succeeds without incident.
Then 'git prune' would run, seemingly without problems, and I would
try and repack my repo with 'git repack -a -d'. Here, things go
boom with SHA1 errors, and subsequent 'git fsck-objects' runs
produce errors.
My local 'git' build is current with the 'master' branch. I've observed
these problems with the Cairo repo on a machine running Debian unstable,
Fedora Core 4, and Fedora Rawhide. The Debian machine uses git built
by the current gcc-4.1 package, FC4 uses its current gcc-4.0 package,
and rawhide uses its current gcc-4.1 package. All these machines are
kept up-to-date with the respective current packages versions for
that distro.
Can anyone out in git-land seeing problems with the Cairo
git repo, or able to duplicate these problems?
Thanks in advance,
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
^ permalink raw reply
* Re: Odd behavior with git and cairo-devel repo
From: Andre Noll @ 2006-06-21 2:46 UTC (permalink / raw)
To: Art Haas; +Cc: git
In-Reply-To: <20060621010030.GP2820@artsapartment.org>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On 20:00, Art Haas wrote:
> $ git clone git://git.cairographics.org/git/cairo cairo
> [ ... git clones the repo without problem ... ]
> $ cd cairo
> $ git fsck-objects
> Floating point exception
This is due to refs_hash_size being zero in mark_reachable().
Both "git fsck-objects --full" and "git repack -a -d" seem to work
fine with the patch below (tested by cloning your repo).
---
Currently, we don't check refs_hash_size size and happily call
lookup_object_refs() even if refs_hash_size is zero which leads to
a division by zero in hash_obj().
Signed-off-by: Andre Noll <maan@systemlinux.org>
---
diff --git a/object-refs.c b/object-refs.c
index 8afa227..a7d49c6 100644
--- a/object-refs.c
+++ b/object-refs.c
@@ -127,6 +127,9 @@ void mark_reachable(struct object *obj,
if (!track_object_refs)
die("cannot do reachability with object refs turned off");
+ /* nothing to lookup */
+ if (!refs_hash_size)
+ return;
/* If we've been here already, don't bother */
if (obj->flags & mask)
return;
--
The only person who always got his work done by Friday was Robinson Crusoe
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: packs and trees
From: Linus Torvalds @ 2006-06-21 3:54 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Nicolas Pitre, Jon Smirl, git
In-Reply-To: <46a038f90606201241x3dec242dicde245a24c3ab9ab@mail.gmail.com>
On Wed, 21 Jun 2006, Martin Langhoff wrote:
>
> If you are asking about the ext3 performance problems, I think Linus
> discussed that a while ago, why unpacked repos are slow (in addition
> to huge), and there were some suggestions of using hashed directory
> indexes.
Yes. I think most distros still default to nonhashed directories, but for
any large-directory case you really want to turn on hashing.
I forget the exact details, it's somethng like
tune2fs -O dir_index
or something to turn it on (if I remember correctly, that will only affect
any directories then created after that, but you can effect that by just
doing a "git repack -a -d" which will remove all old object directories,
and now subsequent directories will be done with indexing on).
Personally, I just ended up using packs extensively, so I think I'm still
running without indexing on all my machines ;)
Linus
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: whitespace cleanup
From: Jakub Narebski @ 2006-06-21 8:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <11508760842024-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
>
> Signed-off-by: Jakub Narebski <jnareb.com>
It should be of course
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Somehow cover letter got lost, and patches did not appear on mailing
list archives.
If the mail will not appear in few hours, I'll resend it to mailing list only.
Probably because git-send-email should ensure LC_ALL=C for Date:
header generation...
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
* [PATCH 1/4] upload-pack: avoid sending an incomplete pack upon failure
From: Junio C Hamano @ 2006-06-21 8:12 UTC (permalink / raw)
To: git
When the repository on the remote side is corrupted, rev-list
spawned from upload-pack would die with error, but pack-objects
that reads from the rev-list happily created a packfile that can
be unpacked by the downloader. When this happens, the resulting
packfile is not corrupted and unpacks cleanly, but the list of
the objects contained in it is not what the protocol exchange
computed.
This update makes upload-pack to monitor its subprocesses, and
when either of them dies with error, sends an incomplete pack
data to the downloader to cause it to fail.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is about "upload-pack is unsafe in corrupt repository"
message I sent about 20 hours ago.
upload-pack.c | 177 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 163 insertions(+), 14 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 979e583..a9a8f2e 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -5,6 +5,9 @@ #include "tag.h"
#include "object.h"
#include "commit.h"
#include "exec_cmd.h"
+#include <signal.h>
+#include <sys/poll.h>
+#include <sys/wait.h>
static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
@@ -33,17 +36,20 @@ static int strip(char *line, int len)
static void create_pack_file(void)
{
- int fd[2];
- pid_t pid;
+ /* Pipes between rev-list to pack-objects and pack-objects to us. */
+ int lp_pipe[2], pu_pipe[2];
+ pid_t pid_rev_list, pid_pack_objects;
int create_full_pack = (nr_our_refs == nr_needs && !nr_has);
+ char data[8193];
+ int buffered = -1;
- if (pipe(fd) < 0)
+ if (pipe(lp_pipe) < 0)
die("git-upload-pack: unable to create pipe");
- pid = fork();
- if (pid < 0)
+ pid_rev_list = fork();
+ if (pid_rev_list < 0)
die("git-upload-pack: unable to fork git-rev-list");
- if (!pid) {
+ if (!pid_rev_list) {
int i;
int args;
const char **argv;
@@ -60,10 +66,10 @@ static void create_pack_file(void)
argv = (const char **) p;
buf = xmalloc(args * 45);
- dup2(fd[1], 1);
+ dup2(lp_pipe[1], 1);
close(0);
- close(fd[0]);
- close(fd[1]);
+ close(lp_pipe[0]);
+ close(lp_pipe[1]);
*p++ = "rev-list";
*p++ = use_thin_pack ? "--objects-edge" : "--objects";
if (create_full_pack || MAX_NEEDS <= nr_needs)
@@ -86,11 +92,154 @@ static void create_pack_file(void)
execv_git_cmd(argv);
die("git-upload-pack: unable to exec git-rev-list");
}
- dup2(fd[0], 0);
- close(fd[0]);
- close(fd[1]);
- execl_git_cmd("pack-objects", "--stdout", NULL);
- die("git-upload-pack: unable to exec git-pack-objects");
+
+ if (pipe(pu_pipe) < 0)
+ die("git-upload-pack: unable to create pipe");
+ pid_pack_objects = fork();
+ if (pid_pack_objects < 0) {
+ /* daemon sets things up to ignore TERM */
+ kill(pid_rev_list, SIGKILL);
+ die("git-upload-pack: unable to fork git-pack-objects");
+ }
+ if (!pid_pack_objects) {
+ dup2(lp_pipe[0], 0);
+ dup2(pu_pipe[1], 1);
+
+ close(lp_pipe[0]);
+ close(lp_pipe[1]);
+ close(pu_pipe[0]);
+ close(pu_pipe[1]);
+ execl_git_cmd("pack-objects", "--stdout", NULL);
+ kill(pid_rev_list, SIGKILL);
+ die("git-upload-pack: unable to exec git-pack-objects");
+ }
+
+ close(lp_pipe[0]);
+ close(lp_pipe[1]);
+
+ /* We read from pu_pipe[0] to capture the pack data.
+ */
+ close(pu_pipe[1]);
+
+ while (1) {
+ const char *who;
+ struct pollfd pfd[2];
+ pid_t pid;
+ int status;
+ ssize_t sz;
+ int pu, pollsize;
+
+ pollsize = 0;
+ pu = -1;
+
+ if (0 <= pu_pipe[0]) {
+ pfd[pollsize].fd = pu_pipe[0];
+ pfd[pollsize].events = POLLIN;
+ pu = pollsize;
+ pollsize++;
+ }
+
+ if (pollsize) {
+ if (poll(pfd, pollsize, -1) < 0) {
+ if (errno != EINTR) {
+ error("poll failed, resuming: %s",
+ strerror(errno));
+ sleep(1);
+ }
+ continue;
+ }
+ if (0 <= pu && (pfd[pu].revents & (POLLIN|POLLHUP))) {
+ /* Data ready; we keep the last byte
+ * to ourselves in case we detect
+ * broken rev-list, so that we can
+ * leave the stream corrupted. This
+ * is unfortunate -- unpack-objects
+ * would happily accept a valid pack
+ * data with trailing garbage, so
+ * appending garbage after we pass all
+ * the pack data is not good enough to
+ * signal breakage to downstream.
+ */
+ char *cp = data;
+ ssize_t outsz = 0;
+ if (0 <= buffered) {
+ *cp++ = buffered;
+ outsz++;
+ }
+ sz = read(pu_pipe[0], cp,
+ sizeof(data) - outsz);
+ if (0 < sz)
+ ;
+ else if (sz == 0) {
+ close(pu_pipe[0]);
+ pu_pipe[0] = -1;
+ }
+ else
+ goto fail;
+ sz += outsz;
+ if (1 < sz) {
+ buffered = data[sz-1] & 0xFF;
+ sz--;
+ }
+ else
+ buffered = -1;
+ sz = xwrite(1, data, sz);
+ if (sz < 0)
+ goto fail;
+ }
+ }
+
+ /* See if the children are still there */
+ if (pid_rev_list || pid_pack_objects) {
+ pid = waitpid(-1, &status, WNOHANG);
+ if (!pid)
+ continue;
+ who = ((pid == pid_rev_list) ? "git-rev-list" :
+ (pid == pid_pack_objects) ? "git-pack-objects" :
+ NULL);
+ if (!who) {
+ if (pid < 0) {
+ error("git-upload-pack: %s",
+ strerror(errno));
+ goto fail;
+ }
+ error("git-upload-pack: we weren't "
+ "waiting for %d", pid);
+ continue;
+ }
+ if (!WIFEXITED(status) || WEXITSTATUS(status) > 0) {
+ error("git-upload-pack: %s died with error.",
+ who);
+ goto fail;
+ }
+ if (pid == pid_rev_list)
+ pid_rev_list = 0;
+ if (pid == pid_pack_objects)
+ pid_pack_objects = 0;
+ if (pid_rev_list || pid_pack_objects)
+ continue;
+ }
+
+ /* both died happily */
+ if (pollsize)
+ continue;
+
+ /* flush the data */
+ if (0 <= buffered) {
+ data[0] = buffered;
+ sz = xwrite(1, data, 1);
+ if (sz < 0)
+ goto fail;
+ fprintf(stderr, "flushed.\n");
+ }
+ return;
+ }
+ fail:
+ if (pid_pack_objects)
+ kill(pid_pack_objects, SIGKILL);
+ if (pid_rev_list)
+ kill(pid_rev_list, SIGKILL);
+ die("git-upload-pack: aborting due to possible repository corruption on the remote side.");
}
static int got_sha1(char *hex, unsigned char *sha1)
--
1.4.0.gbb3f
^ permalink raw reply related
* [PATCH 2/4] upload-pack: prepare for sideband message support.
From: Junio C Hamano @ 2006-06-21 8:12 UTC (permalink / raw)
To: git
This does not implement sideband for propagating the status to
the downloader yet, but add code to capture the standard error
output from the pack-objects process in preparation for sending
it off to the client when the protocol extension allows us to do
so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
pack-objects.c | 4 ++++
upload-pack.c | 46 +++++++++++++++++++++++++++++++++++++++-------
2 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/pack-objects.c b/pack-objects.c
index 179560f..7a8c16c 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -1221,6 +1221,10 @@ int main(int argc, char **argv)
local = 1;
continue;
}
+ if (!strcmp("--progress", arg)) {
+ progress = 1;
+ continue;
+ }
if (!strcmp("--incremental", arg)) {
incremental = 1;
continue;
diff --git a/upload-pack.c b/upload-pack.c
index a9a8f2e..13eaa22 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -36,11 +36,13 @@ static int strip(char *line, int len)
static void create_pack_file(void)
{
- /* Pipes between rev-list to pack-objects and pack-objects to us. */
- int lp_pipe[2], pu_pipe[2];
+ /* Pipes between rev-list to pack-objects, pack-objects to us
+ * and pack-objects error stream for progress bar.
+ */
+ int lp_pipe[2], pu_pipe[2], pe_pipe[2];
pid_t pid_rev_list, pid_pack_objects;
int create_full_pack = (nr_our_refs == nr_needs && !nr_has);
- char data[8193];
+ char data[8193], progress[128];
int buffered = -1;
if (pipe(lp_pipe) < 0)
@@ -95,6 +97,8 @@ static void create_pack_file(void)
if (pipe(pu_pipe) < 0)
die("git-upload-pack: unable to create pipe");
+ if (pipe(pe_pipe) < 0)
+ die("git-upload-pack: unable to create pipe");
pid_pack_objects = fork();
if (pid_pack_objects < 0) {
/* daemon sets things up to ignore TERM */
@@ -104,12 +108,15 @@ static void create_pack_file(void)
if (!pid_pack_objects) {
dup2(lp_pipe[0], 0);
dup2(pu_pipe[1], 1);
+ dup2(pe_pipe[1], 2);
close(lp_pipe[0]);
close(lp_pipe[1]);
close(pu_pipe[0]);
close(pu_pipe[1]);
- execl_git_cmd("pack-objects", "--stdout", NULL);
+ close(pe_pipe[0]);
+ close(pe_pipe[1]);
+ execl_git_cmd("pack-objects", "--stdout", "--progress", NULL);
kill(pid_rev_list, SIGKILL);
die("git-upload-pack: unable to exec git-pack-objects");
}
@@ -117,20 +124,23 @@ static void create_pack_file(void)
close(lp_pipe[0]);
close(lp_pipe[1]);
- /* We read from pu_pipe[0] to capture the pack data.
+ /* We read from pe_pipe[0] to capture stderr output for
+ * progress bar, and pu_pipe[0] to capture the pack data.
*/
+ close(pe_pipe[1]);
close(pu_pipe[1]);
while (1) {
const char *who;
+ char *cp;
struct pollfd pfd[2];
pid_t pid;
int status;
ssize_t sz;
- int pu, pollsize;
+ int pe, pu, pollsize;
pollsize = 0;
- pu = -1;
+ pe = pu = -1;
if (0 <= pu_pipe[0]) {
pfd[pollsize].fd = pu_pipe[0];
@@ -138,6 +148,12 @@ static void create_pack_file(void)
pu = pollsize;
pollsize++;
}
+ if (0 <= pe_pipe[0]) {
+ pfd[pollsize].fd = pe_pipe[0];
+ pfd[pollsize].events = POLLIN;
+ pe = pollsize;
+ pollsize++;
+ }
if (pollsize) {
if (poll(pfd, pollsize, -1) < 0) {
@@ -187,6 +203,22 @@ static void create_pack_file(void)
if (sz < 0)
goto fail;
}
+ if (0 <= pe && (pfd[pe].revents & (POLLIN|POLLHUP))) {
+ /* Status ready; we do not use it for now,
+ * but later we will add side-band to send it
+ * to the other side.
+ */
+ sz = read(pe_pipe[0], progress,
+ sizeof(progress));
+ if (0 < sz)
+ write(2, progress, sz);
+ else if (sz == 0) {
+ close(pe_pipe[0]);
+ pe_pipe[0] = -1;
+ }
+ else
+ goto fail;
+ }
}
/* See if the children are still there */
--
1.4.0.gbb3f
^ permalink raw reply related
* [PATCH 3/4] Retire git-clone-pack
From: Junio C Hamano @ 2006-06-21 8:14 UTC (permalink / raw)
To: git
The program is not used by git-clone since git-fetch-pack was extended
to allow its caller do what git-clone-pack alone did, and git-clone was
updated to use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Logically this does not belong to the series, but retiring
clone-pack lets me get away without having to update the
callers of the function I'll be updating in the next one.
.gitignore | 1
Documentation/git-clone-pack.txt | 64 ------------
Documentation/git-clone.txt | 4 -
Documentation/git-receive-pack.txt | 3 -
Documentation/git-upload-pack.txt | 2
Documentation/git.txt | 6 -
INSTALL | 2
Makefile | 2
clone-pack.c | 186 ------------------------------------
9 files changed, 7 insertions(+), 263 deletions(-)
diff --git a/.gitignore b/.gitignore
index afd0876..65aa939 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,7 +17,6 @@ git-cherry
git-cherry-pick
git-clean
git-clone
-git-clone-pack
git-commit
git-commit-tree
git-convert-objects
diff --git a/Documentation/git-clone-pack.txt b/Documentation/git-clone-pack.txt
deleted file mode 100644
index 09f43ee..0000000
--- a/Documentation/git-clone-pack.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-git-clone-pack(1)
-=================
-
-NAME
-----
-git-clone-pack - Clones a repository by receiving packed objects
-
-
-SYNOPSIS
---------
-'git-clone-pack' [--exec=<git-upload-pack>] [<host>:]<directory> [<head>...]
-
-DESCRIPTION
------------
-Clones a repository into the current repository by invoking
-'git-upload-pack', possibly on the remote host via ssh, in
-the named repository, and stores the sent pack in the local
-repository.
-
-OPTIONS
--------
---exec=<git-upload-pack>::
- Use this to specify the path to 'git-upload-pack' on the
- remote side, if it is not found on your $PATH.
- Installations of sshd ignore the user's environment
- setup scripts for login shells (e.g. .bash_profile) and
- your privately installed git may not be found on the system
- default $PATH. Another workaround suggested is to set
- up your $PATH in ".bashrc", but this flag is for people
- who do not want to pay the overhead for non-interactive
- shells by having a lean .bashrc file (they set most of
- the things up in .bash_profile).
-
-<host>::
- A remote host that houses the repository. When this
- part is specified, 'git-upload-pack' is invoked via
- ssh.
-
-<directory>::
- The repository to sync from.
-
-<head>...::
- The heads to update. This is relative to $GIT_DIR
- (e.g. "HEAD", "refs/heads/master"). When unspecified,
- all heads are updated to match the remote repository.
-+
-Usually all the refs from existing repository are stored
-under the same name in the new repository. Giving explicit
-<head> arguments instead writes the object names and refs to
-the standard output, just like get-fetch-pack does.
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano.
-
-
-GIT
----
-Part of the gitlink:git[7] suite
-
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index a90521e..f973c64 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -62,7 +62,7 @@ OPTIONS
--quiet::
-q::
Operate quietly. This flag is passed to "rsync" and
- "git-clone-pack" commands when given.
+ "git-fetch-pack" commands when given.
-n::
No checkout of HEAD is performed after the clone is complete.
@@ -85,7 +85,7 @@ OPTIONS
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is handled
- by 'git-clone-pack', '--exec=<upload-pack>' is passed to
+ by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
the command to specify non-default path for the command
run on the other end.
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 60debca..f9457d4 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -18,8 +18,7 @@ information fed from the remote end.
This command is usually not invoked directly by the end user.
The UI for the protocol is on the 'git-send-pack' side, and the
program pair is meant to be used to push updates to remote
-repository. For pull operations, see 'git-fetch-pack' and
-'git-clone-pack'.
+repository. For pull operations, see 'git-fetch-pack'.
The command allows for creation and fast forwarding of sha1 refs
(heads/tags) on the remote end (strictly speaking, it is the
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
index 4795e98..b2c9307 100644
--- a/Documentation/git-upload-pack.txt
+++ b/Documentation/git-upload-pack.txt
@@ -12,7 +12,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Invoked by 'git-clone-pack' and/or 'git-fetch-pack', learns what
+Invoked by 'git-fetch-pack', learns what
objects the other side is missing, and sends them after packing.
This command is usually not invoked directly by the end user.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index d4472b5..51f20c6 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -192,10 +192,6 @@ the working tree.
Synching repositories
~~~~~~~~~~~~~~~~~~~~~
-gitlink:git-clone-pack[1]::
- Clones a repository into the current repository (engine
- for ssh and local transport).
-
gitlink:git-fetch-pack[1]::
Updates from a remote repository (engine for ssh and
local transport).
@@ -237,7 +233,7 @@ gitlink:git-update-server-info[1]::
clients discover references and packs on it.
gitlink:git-upload-pack[1]::
- Invoked by 'git-clone-pack' and 'git-fetch-pack' to push
+ Invoked by 'git-fetch-pack' to push
what are asked for.
gitlink:git-upload-tar[1]::
diff --git a/INSTALL b/INSTALL
index 63af8ec..f8337e2 100644
--- a/INSTALL
+++ b/INSTALL
@@ -96,7 +96,7 @@ Issues of note:
$ mkdir manual && cd manual
$ git init-db
- $ git clone-pack git://git.kernel.org/pub/scm/git/git.git man html |
+ $ git fetch-pack git://git.kernel.org/pub/scm/git/git.git man html |
while read a b
do
echo $a >.git/$b
diff --git a/Makefile b/Makefile
index 0887945..ae5e8d7 100644
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,7 @@ SIMPLE_PROGRAMS = \
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
- git-checkout-index$X git-clone-pack$X \
+ git-checkout-index$X \
git-convert-objects$X git-fetch-pack$X git-fsck-objects$X \
git-hash-object$X git-index-pack$X git-local-fetch$X \
git-mailinfo$X git-merge-base$X \
diff --git a/clone-pack.c b/clone-pack.c
deleted file mode 100644
index a4370f5..0000000
--- a/clone-pack.c
+++ /dev/null
@@ -1,186 +0,0 @@
-#include "cache.h"
-#include "refs.h"
-#include "pkt-line.h"
-
-static const char clone_pack_usage[] =
-"git-clone-pack [--exec=<git-upload-pack>] [<host>:]<directory> [<heads>]*";
-static const char *exec = "git-upload-pack";
-
-static int quiet = 0;
-
-static void clone_handshake(int fd[2], struct ref *ref)
-{
- unsigned char sha1[20];
-
- while (ref) {
- packet_write(fd[1], "want %s\n", sha1_to_hex(ref->old_sha1));
- ref = ref->next;
- }
- packet_flush(fd[1]);
-
- /* We don't have nuttin' */
- packet_write(fd[1], "done\n");
- if (get_ack(fd[0], sha1))
- error("Huh! git-clone-pack got positive ack for %s", sha1_to_hex(sha1));
-}
-
-static int is_master(struct ref *ref)
-{
- return !strcmp(ref->name, "refs/heads/master");
-}
-
-static void write_one_ref(struct ref *ref)
-{
- char *path = git_path("%s", ref->name);
- int fd;
- char *hex;
-
- if (!strncmp(ref->name, "refs/", 5) &&
- check_ref_format(ref->name + 5)) {
- error("refusing to create funny ref '%s' locally", ref->name);
- return;
- }
-
- if (safe_create_leading_directories(path))
- die("unable to create leading directory for %s", ref->name);
- fd = open(path, O_CREAT | O_EXCL | O_WRONLY, 0666);
- if (fd < 0)
- die("unable to create ref %s", ref->name);
- hex = sha1_to_hex(ref->old_sha1);
- hex[40] = '\n';
- if (write(fd, hex, 41) != 41)
- die("unable to write ref %s", ref->name);
- close(fd);
-}
-
-static void write_refs(struct ref *ref)
-{
- struct ref *head = NULL, *head_ptr, *master_ref;
- char *head_path;
-
- /* Upload-pack must report HEAD first */
- if (!strcmp(ref->name, "HEAD")) {
- head = ref;
- ref = ref->next;
- }
- head_ptr = NULL;
- master_ref = NULL;
- while (ref) {
- if (is_master(ref))
- master_ref = ref;
- if (head &&
- !memcmp(ref->old_sha1, head->old_sha1, 20) &&
- !strncmp(ref->name, "refs/heads/",11) &&
- (!head_ptr || ref == master_ref))
- head_ptr = ref;
-
- write_one_ref(ref);
- ref = ref->next;
- }
- if (!head) {
- fprintf(stderr, "No HEAD in remote.\n");
- return;
- }
-
- head_path = strdup(git_path("HEAD"));
- if (!head_ptr) {
- /*
- * If we had a master ref, and it wasn't HEAD, we need to undo the
- * symlink, and write a standalone HEAD. Give a warning, because that's
- * really really wrong.
- */
- if (master_ref) {
- error("HEAD doesn't point to any refs! Making standalone HEAD");
- unlink(head_path);
- }
- write_one_ref(head);
- free(head_path);
- return;
- }
-
- /* We reset to the master branch if it's available */
- if (master_ref)
- return;
-
- fprintf(stderr, "Setting HEAD to %s\n", head_ptr->name);
-
- /*
- * Uhhuh. Other end didn't have master. We start HEAD off with
- * the first branch with the same value.
- */
- if (create_symref(head_path, head_ptr->name) < 0)
- die("unable to link HEAD to %s", head_ptr->name);
- free(head_path);
-}
-
-static int clone_pack(int fd[2], int nr_match, char **match)
-{
- struct ref *refs;
- int status;
-
- get_remote_heads(fd[0], &refs, nr_match, match, 1);
- if (!refs) {
- packet_flush(fd[1]);
- die("no matching remote head");
- }
- clone_handshake(fd, refs);
-
- status = receive_keep_pack(fd, "git-clone-pack", quiet);
- if (!quiet)
- fprintf(stderr, "\n");
-
- if (!status) {
- if (nr_match == 0)
- write_refs(refs);
- else
- while (refs) {
- printf("%s %s\n",
- sha1_to_hex(refs->old_sha1),
- refs->name);
- refs = refs->next;
- }
- }
- return status;
-}
-
-int main(int argc, char **argv)
-{
- int i, ret, nr_heads;
- char *dest = NULL, **heads;
- int fd[2];
- pid_t pid;
-
- setup_git_directory();
-
- nr_heads = 0;
- heads = NULL;
- for (i = 1; i < argc; i++) {
- char *arg = argv[i];
-
- if (*arg == '-') {
- if (!strcmp("-q", arg)) {
- quiet = 1;
- continue;
- }
- if (!strncmp("--exec=", arg, 7)) {
- exec = arg + 7;
- continue;
- }
- usage(clone_pack_usage);
- }
- dest = arg;
- heads = argv + i + 1;
- nr_heads = argc - i - 1;
- break;
- }
- if (!dest)
- usage(clone_pack_usage);
- pid = git_connect(fd, dest, exec);
- if (pid < 0)
- return 1;
- ret = clone_pack(fd, nr_heads, heads);
- close(fd[0]);
- close(fd[1]);
- finish_connect(pid);
- return ret;
-}
--
1.4.0.gbb3f
^ permalink raw reply related
* Re: [RFC] gitweb wishlist and TODO list
From: Josef Weidendorfer @ 2006-06-21 8:56 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Michael Gernoth
In-Reply-To: <20060620215331.GB25183@cip.informatik.uni-erlangen.de>
On Tuesday 20 June 2006 23:53, you wrote:
> he didn't do so far. So I use this opportunity. Maybe something else
> would be much more handier: Use gitweb to request the log and shortlog
> of a directory tree, like git-whatchanged arch/i386 does for example.
> Maybe it is already possible and I missed it?
There aren't any links, but:
On the bottom of a commit, you can click on "history" for blobs.
Changing the URL afterwards (the f= arg) can give you the history of
a directory.
I just tried, and in fact it works. But "Diff to current" does not
work for directories.
It would be nice to have a list of the files in the directory
touched by the given commits.
Josef
^ permalink raw reply
* [PATCH] Fix possible out-of-bounds array access
From: Uwe Zeisberger @ 2006-06-21 9:04 UTC (permalink / raw)
To: git
In-Reply-To: <20060620160836.GA20153@informatik.uni-freiburg.de>
If match is "", match[-1] is accessed. Let pathspec_matches return 1 in that
case indicating that "" matches everything.
Incidently this fixes git-grep'ing in ".".
Signed-off-by: Uwe Zeisberger <Uwe_Zeisberger@digi.com>
---
builtin-grep.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 9806499..f7767bb 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -29,10 +29,11 @@ static int pathspec_matches(const char *
int matchlen = strlen(match);
const char *cp, *meta;
- if ((matchlen <= namelen) &&
- !strncmp(name, match, matchlen) &&
- (match[matchlen-1] == '/' ||
- name[matchlen] == '\0' || name[matchlen] == '/'))
+ if (!matchlen ||
+ ((matchlen <= namelen) &&
+ !strncmp(name, match, matchlen) &&
+ (match[matchlen-1] == '/' ||
+ name[matchlen] == '\0' || name[matchlen] == '/')))
return 1;
if (!fnmatch(match, name, 0))
return 1;
--
1.4.0
--
Uwe Zeisberger
http://www.google.com/search?q=12+mol+in+dozen
^ permalink raw reply related
* Re: [PATCH 0/3] Minor gitweb modifications and cleanups
From: Junio C Hamano @ 2006-06-21 9:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11508760843417-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This series of patches is based on git.git 'next' branch
> 69d830d1a3a1236036bd0f84dd9794d7c8d34b3f
>
> My future gitweb-related batches will be based on this series.
>
> ---
>
> gitweb/gitweb.cgi | 53 +++++++++++++++++++++++++++++++----------------------
> gitweb/gitweb.css | 4 ++--
> 2 files changed, 33 insertions(+), 24 deletions(-)
>
> --
> Jakub Narebski
> Poland
All three applied cleanly (finally!), but with hand munging of
Date: field.
I think git-send-email should internally do LC_ALL=C or stop
using strftime() or both.
^ permalink raw reply
* [PATCH] send-email: Use setlocale in addition to $ENV{LC_ALL} to set locale
From: Jakub Narebski @ 2006-06-21 9:12 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <7v3bdy5178.fsf@assigned-by-dhcp.cox.net>
$ENV{LC_ALL} = 'C'; does not change locale used by strftime.
Use setlocale( LC_ALL, 'C' ); instead.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
git-send-email.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
7c796152570e28d3f95c17e93864c6abc8edef24
diff --git a/git-send-email.perl b/git-send-email.perl
index 7b1cca7..56949dd 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -24,7 +24,8 @@ use Data::Dumper;
# most mail servers generate the Date: header, but not all...
$ENV{LC_ALL} = 'C';
-use POSIX qw/strftime/;
+use POSIX qw/strftime setlocale LC_ALL/;
+setlocale( &LC_ALL, 'C' );
my $have_email_valid = eval { require Email::Valid; 1 };
my $smtp;
--
1.3.0
^ permalink raw reply related
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