* Re: [PATCH] tests: disable interactive hunk selection tests if perl not available
From: Thomas Rast @ 2009-08-18 8:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090818061244.GA20659@coredump.intra.peff.net>
Jeff King wrote:
> +++ b/t/lib-patch-mode.sh
> @@ -1,5 +1,10 @@
> . ./test-lib.sh
>
> +if ! test_have_prereq PERL; then
Thanks. I always forget about these little things...
Acked-By: Thomas Rast <trast@student.ethz.ch>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] add -p: do not attempt to coalesce mode changes
From: Kirill Smelkov @ 2009-08-18 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Jeff King, git
In-Reply-To: <7vtz09lz2r.fsf@alter.siamese.dyndns.org>
On Sat, Aug 15, 2009 at 11:19:24AM -0700, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > Hmm. I briefly considered worrying about futureproofing, but then
> > decided it wasn't worth it since we also rely on
> > coalesce_overlapping_hunks only being run over the hunks of a single
> > file.
>
> Thanks, all.
Thomas, Jeff, Junio,
Thanks for fixing this!
^ permalink raw reply
* Re: [PATCH] git-instaweb: fix mod_perl detection for apache2
From: Jakub Narebski @ 2009-08-18 7:45 UTC (permalink / raw)
To: Mark A Rada; +Cc: Junio C Hamano, git
In-Reply-To: <3300D840-9BAB-4233-B949-6A5B300CD9A8@mailservices.uwaterloo.ca>
On Wed, 15 Aug 2009, Mark A Rada wrote:
> On 10-Aug-09, at 4:55 AM, Jakub Narebski wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>> Thanks. That sounds like an ancient bug that in turn perhaps
>>> suggests nobody uses instaweb. Will apply to 'maint'..
>>
>> Hmmm... taking a peek at current "Git User's Survey 2009" results
>> http://www.survs.com/shareResults?survey=2PIMZGU0&rndm=678J66QRA2
>>
>> 11. What Git interfaces, implementations, frontends and tools do you
>> use?
>>
>> git-instaweb 3% 77 / 2712
>>
>> 16. How often do you use the following forms of git commands or extra
>> git tools?
>>
>> git instaweb
>> never: 1983 - 79%
>> rarely: 208 - 8%
>> sometimes: 50 - 2%
>> often: 9 - 0%
>>
>> Total respondents 2506
>>
>
> Does this means it may be taken off the menu in the not too distant
> future or deprecated?
I don't think so. We keep git-relink, which almost nobody uses, and
few know what it does.
I guess that git-instaweb is not advertised enough, but that might
change, as Scott Chacon in "Pro Git" mentions / covers git-instaweb.
P.S. I'd like to create GIT::Web, which would use (contrary to gitweb)
many CPAN modules (and PAR to help installing it with dependencies),
which would use HTTP::Engine (and therefore run as CGI, FastCGI,
mod_perl and standalone HTTP::Server::Simple), and be similar in
structure to SVN::Web. With it using HTTP::Server::Simple git-instaweb
would be needed less... But it is in "Duke Nuke Forever" (or
packv4 ;-) future...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Johannes Sixt @ 2009-08-18 7:15 UTC (permalink / raw)
To: msysGit; +Cc: Junio C Hamano, Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
This is a minimal fix to compile block-sha1 on Windows. I did not do any
benchmarks whether the implementation of ntohl() is actually faster than
bytewise access and shifts.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I would appreciate if our Windows experts could tell whether the
implementation of ntohl/htonl is worth its money or whether we should
go with the generic byte access plus shifts.
the function call over
block-sha1/sha1.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index a1228cf..67c1ee8 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -7,7 +7,11 @@
*/
#include <string.h>
+#ifndef _WIN32
#include <arpa/inet.h>
+#else
+#include <winsock2.h>
+#endif
#include "sha1.h"
--
1.6.4.1179.g9a91.dirty
^ permalink raw reply related
* [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Tom Preston-Werner @ 2009-08-18 7:04 UTC (permalink / raw)
To: git; +Cc: Tom Preston-Werner
A post-upload-pack hook is desirable for Git hosts that need to
collect statistics on how many clones and/or fetches are made
on each repository.
The hook is called with either "clone" or "fetch" as the only
argument, depending on whether a full pack file was sent to the
client or not.
Signed-off-by: Tom Preston-Werner <tom@mojombo.com>
---
upload-pack.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index f7d308a..96231dc 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -141,6 +141,13 @@ static int do_rev_list(int fd, void *create_full_pack)
return 0;
}
+static void run_post_upload_pack_hook(int create_full_pack)
+{
+ const char *fetch_type;
+ fetch_type = (create_full_pack) ? "clone" : "fetch";
+ run_hook(get_index_file(), "post-upload-pack", fetch_type);
+}
+
static void create_pack_file(void)
{
struct async rev_list;
@@ -314,6 +321,8 @@ static void create_pack_file(void)
}
if (use_sideband)
packet_flush(1);
+
+ run_post_upload_pack_hook(create_full_pack);
return;
fail:
--
1.6.3.1
^ permalink raw reply related
* Re: Continue git clone after interruption
From: Tomasz Kontusz @ 2009-08-18 6:58 UTC (permalink / raw)
To: git
In-Reply-To: <vpqskfphe2k.fsf@bauges.imag.fr>
Dnia 2009-08-18, wto o godzinie 07:43 +0200, Matthieu Moy pisze:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Mon, 17 Aug 2009, Tomasz Kontusz wrote:
> >
> >> is anybody working on making it possible to continue git clone after
> >> interruption? It would be quite useful for people with bad internet
> >> connection (I was downloading a big repo lately, and it was a bit
> >> frustrating to start it over every time git stopped at ~90%).
> >
> > Unfortunately, we did not have enough GSoC slots for the project to allow
> > restartable clones.
> >
> > There were discussions about how to implement this on the list,
> > though.
>
> And a paragraph on the wiki:
>
> http://git.or.cz/gitwiki/SoC2009Ideas#RestartableClone
Ok, so it looks like it's not implementable without some kind of cache
server-side, so the server would know what the pack it was sending
looked like.
But here's my idea: make server send objects in different order (the
newest commit + whatever it points to first, then next one,then
another...). Then it would be possible to look at what we got, tell
server we have nothing, and want [the newest commit that was not
complete]. I know the reason why it is sorted the way it is, but I think
that the way data is stored after clone is clients problem, so the
client should reorganize packs the way it wants.
Tomasz K.
^ permalink raw reply
* git find (was: [RFC PATCH v3 8/8] --sparse for porcelains)
From: Jakub Narebski @ 2009-08-18 6:25 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: skillzero, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0908171843x6ab0763dqff7e8aea0443c374@mail.gmail.com>
On Tue, Aug 18, 2009, Nguyen Thai Ngoc Duy wrote:
> On Tue, Aug 18, 2009 at 7:34 AM, <skillzero@gmail.com> wrote:
> > I would like it to git grep to not search paths outside the sparse
> > area (although --no-sparse would be nice for git grep in case you did
> > want to search everything). The main reason I want sparse checkouts is
> > for performance reasons. For example, git grep can take 10 minutes on
> > my full repository so excluding paths outside the sparse area would
> > reduce that to a few seconds.
>
> That's a porcelain question that I'd leave it for now. FWIW you can do
> something like this:
>
> git ls-files -v|grep '^H'|cut -c 2-|xargs git grep
>
> /me misses "cleartool find"
Well, I also think that it would be nice and useful to have "git find"
in addition to current "git grep".
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] tests: disable interactive hunk selection tests if perl not available
From: Jeff King @ 2009-08-18 6:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
These are all backed by git-add--interactive.perl under the
hood.
Signed-off-by: Jeff King <peff@peff.net>
---
On top of tr/reset-checkout-patch.
t/lib-patch-mode.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/t/lib-patch-mode.sh b/t/lib-patch-mode.sh
index afb4b66..75a3ee2 100755
--- a/t/lib-patch-mode.sh
+++ b/t/lib-patch-mode.sh
@@ -1,5 +1,10 @@
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping --patch tests, perl not available'
+ test_done
+fi
+
set_state () {
echo "$3" > "$1" &&
git add "$1" &&
--
1.6.4.301.g8099b
^ permalink raw reply related
* Re: [PATCH v2] remove ARM and Mozilla SHA1 implementations
From: David Aguilar @ 2009-08-18 5:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0908172007590.6044@xanadu.home>
On Mon, Aug 17, 2009 at 08:09:56PM -0400, Nicolas Pitre wrote:
>
> Makefile | 26 +------
>
> -ifneq (,$(findstring arm,$(uname_M)))
> - ARM_SHA1 = YesPlease
> - NO_MKSTEMPS = YesPlease
> -endif
When I added NO_MKSTEMPS I was being conservative when defining
it on arm (I wasn't able to test that platform).
Looks like it wasn't needed afterall.
Thanks.
--
David
^ permalink raw reply
* Re: [PATCH][resend] git-svn: Respect GIT_SSH setting
From: Karthik R @ 2009-08-18 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <4A89EC07.2010402@fastmail.fm>
Karthik R wrote:
> Junio C Hamano wrote:
>> Karthik R <karthikr@fastmail.fm> writes:
>>
>>
>>> +# If GIT_SSH is set, also set SVN_SSH...
>>> +$ENV{SVN_SSH} = $ENV{GIT_SSH} if defined $ENV{GIT_SSH};
>>> +# ... and escape \s in shell-variable on Windows
>>> +if ($^O eq 'MSWin32' || $^O eq 'msys') {
>>> + $ENV{SVN_SSH} =~ s/\\/\\\\/g if defined $ENV{SVN_SSH};
>>> +}
>>> +
>>>
>>
>> Two questions.
>>
>> - What if a user has SVN_SSH exported _and_ wants to use a different
>> one
>> from the one s/he uses for git? Naturally such a user would set both
>> environment variables and differently, but this seems to override the
>> value in SVN_SSH;
>>
> Do you mean user wants to use a different one with "git svn ...
> svn+ssh://" (than the one with "git clone ssh://") ?
> In this case
> - defining SVN_SSH, but not GIT_SSH will still work (with this patch,
> GIT_SSH overrides)
> - but SVN_SSH needs to have \\s.
> So unless the user already knew of this quirk, we'll only see
> unescaped \s - so it *does* make sense to escape the \s (if the user
> knew, then too many escaped \s still work).
>> - Can a user have SVN_SSH exported, on MSWin32 or msys, and use svn
>> outside git? If so, what does the value of SVN_SSH look like?
>> Does it
>> typically have necessary doubling of backslashes already?
>>
> With subversion for Windows, these \\s are not needed (but doesn't
> cause any break). The doubling is something to do with the bash (in
> msys) I think.
I was wrong... the \\ seems to be a subversion issue. This s/\\/ line in
this patch would at best be a work-around (necessary because GIT_SSH
doesn't have this bug).
http://subversion.tigris.org/issues/show_bug.cgi?id=3454 (GIT_SSH would
look like the last one in the list - and with this patch, SVN_SSH can
also look the same)
^ permalink raw reply
* Re: Continue git clone after interruption
From: Matthieu Moy @ 2009-08-18 5:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tomasz Kontusz, git
In-Reply-To: <alpine.DEB.1.00.0908171430010.4991@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 17 Aug 2009, Tomasz Kontusz wrote:
>
>> is anybody working on making it possible to continue git clone after
>> interruption? It would be quite useful for people with bad internet
>> connection (I was downloading a big repo lately, and it was a bit
>> frustrating to start it over every time git stopped at ~90%).
>
> Unfortunately, we did not have enough GSoC slots for the project to allow
> restartable clones.
>
> There were discussions about how to implement this on the list,
> though.
And a paragraph on the wiki:
http://git.or.cz/gitwiki/SoC2009Ideas#RestartableClone
--
Matthieu
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Marius Storm-Olsen @ 2009-08-18 5:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172134150.8306@pacific.mpi-cbg.de>
Johannes Schindelin said the following on 17.08.2009 21:36:
> Hi,
>
> On Mon, 17 Aug 2009, Reece Dunn wrote:
>
>> 2009/8/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>>> On Tue, 18 Aug 2009, Frank Li wrote:
>>>
>>>> Some compiler such as MSVC can't support declear variable at mid of
>>>> funtion at c file.
>>> Please wrap your commit messages after 76 characters.
>>>
>>>> Signed-off-by: Frank Li <lznuaa@gmail.com>
>>>> ---
>>> How about this instead?
>>>
>>> Avoid declaration after instruction
>>>
>>> Microsoft Visual C++ does not understand this C99 style.
>>>
>>> ?
>>>
>>> The patch itself is good.
>> Shouldn't GCC be changed to use -std=c89 as well to pick up errors for
>> compilers that don't support c99 (like the Microsoft Visual C++ C
>> compiler)?
>
> Hmm. I played with the thought of adding -Werror -Wno-pointer-to-int-cast
> -Wold-style-definition -Wdeclaration-after-statement like Junio described
> in one of his mails for MinGW (as we _know_ what compiler we have there).
>
> Dunno.
IMO it would be a good change. We should not have any of those anyways..
--
.marius
^ permalink raw reply
* Re: [PATCH 05/11] Remove va_copy at MSVC because there are va_copy.
From: Frank Li @ 2009-08-18 5:06 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git, msysgit, Johannes.Schindelin
In-Reply-To: <4A898B27.3040507@gnu.org>
>
> #ifndef va_copy
> #define va_copy(dst, src) ((dst) = (src))
> #endif
>
> if it works on MSVC?
>
> Paolo
>
I test it, it works.
^ permalink raw reply
* Re: [PATCH 04/11] Add _MSC_VER predefine macro to make same behaviors with __MINGW32__ Enable MSVC build. MSVC have the save behaviors with msysgit.
From: tom fogal @ 2009-08-18 5:06 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysgit
In-Reply-To: <1976ea660908171829se49abf0j5b7d45a74e4c67a7@mail.gmail.com>
Frank Li <lznuaa@gmail.com> writes:
> >
> > Test whether WIN32 is defined rather than __MINGW32__
>
> I think WIN32 is better, how about 64bit build case?
> In 64bit environment, VC define WIN64 not WIN32.
Actually, "_WIN32" is always defined using `cl', even in 64bit mode.
64bit compilation additionally defines "_WIN64", FWIW.
-tom
^ permalink raw reply
* Re: [PATCH][resend] git-svn: Respect GIT_SSH setting
From: Karthik R @ 2009-08-18 4:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908180117140.8306@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 17 Aug 2009, Karthik R wrote:
>
>
>> Setting GIT_SSH when using "git svn clone svn+ssh://..." does not
>> override the default ssh; SVN_SSH needed to be set instead.
>>
>
> This is now in past tense, no?
>
>
Yes... this is all in the past tense now :) ... should be "did not
override the default ssh". I'll fix it if I have to resend the patch for
a different reason.
>> diff --git a/git-svn.perl b/git-svn.perl
>> index b0bfb74..9bc1e71 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -21,6 +21,13 @@ $Git::SVN::default_ref_id = $ENV{GIT_SVN_ID} || 'git-svn';
>> $Git::SVN::Ra::_log_window_size = 100;
>> $Git::SVN::_minimize_url = 'unset';
>>
>> +# If GIT_SSH is set, also set SVN_SSH...
>> +$ENV{SVN_SSH} = $ENV{GIT_SSH} if defined $ENV{GIT_SSH};
>> +# ... and escape \s in shell-variable on Windows
>> +if ($^O eq 'MSWin32' || $^O eq 'msys') {
>> + $ENV{SVN_SSH} =~ s/\\/\\\\/g if defined $ENV{SVN_SSH};
>> +}
>>
>
> This is a change from before... I do not know if it is a good one, as
> SVN_SSH could be defined differently by the user, no? In that case, the
> user was most likely using the correct amount of backslashes...
>
Dscho, The *correct* amount of backslashes is 1 (per dir) - same as used
with GIT_SSH. If the user has set SVN_SSH but not GIT_SSH (most likely
without escaping \), then fixing up SVN_SSH for use with git-svn is not
a bad thing.
I did this change to retain existing behavior (using SVN_SSH to
override) even when user doesn't know the \\ quirk - or if the user has
set it for some other non-msys version of svn.
> So maybe it was correct to make this dependent on "if defined
> $ENV{GIT_SSH}", and maybe it should be dependent on "&& !defined
> $ENV{SVN_SSH}" as well...
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: [PATCH] read-tree: Fix regression with creation of a new index file.
From: Stephen Boyd @ 2009-08-18 3:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alexandre Julliard, git
In-Reply-To: <alpine.DEB.1.00.0908180018020.8306@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> diff --git a/builtin-read-tree.c b/builtin-read-tree.c
> index 9c2d634..d649c56 100644
> --- a/builtin-read-tree.c
> +++ b/builtin-read-tree.c
> @@ -113,14 +113,14 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
> argc = parse_options(argc, argv, unused_prefix, read_tree_options,
> read_tree_usage, 0);
>
> - if (read_cache_unmerged() && (opts.prefix || opts.merge))
> - die("You need to resolve your current index first");
> -
> prefix_set = opts.prefix ? 1 : 0;
> if (1 < opts.merge + opts.reset + prefix_set)
> die("Which one? -m, --reset, or --prefix?");
> stage = opts.merge = (opts.reset || opts.merge || prefix_set);
>
> + if (opts.merge && (read_cache_unmerged() && !prefix_set && !opts.reset))
>
This looks more compact but I think the !prefix_set check is wrong.
Yes, we want to do read_cache_unmerged() if we're doing some sort of
merging operation. But we want to die() when either -m or --prefix is
used. Therefore, die() if we're not doing a --reset. So we might as well
just check that case and nothing else.
The original patch from Alexandre is correct, but if you want to avoid
extra nesting I suppose you could do something like the patch below.
Thanks.
---
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 9c2d634..c6d5b49 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -113,14 +113,14 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
argc = parse_options(argc, argv, unused_prefix, read_tree_options,
read_tree_usage, 0);
- if (read_cache_unmerged() && (opts.prefix || opts.merge))
- die("You need to resolve your current index first");
-
prefix_set = opts.prefix ? 1 : 0;
if (1 < opts.merge + opts.reset + prefix_set)
die("Which one? -m, --reset, or --prefix?");
stage = opts.merge = (opts.reset || opts.merge || prefix_set);
+ if (opts.merge && read_cache_unmerged() && !opts.reset)
+ die("You need to resolve your current index first");
^ permalink raw reply related
* Re: [PATCH 6/6 (v4)] support for path name caching in rev-cache
From: Nicolas Pitre @ 2009-08-18 3:24 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <op.uys3qwlmtdk399@sirnot.private>
On Mon, 17 Aug 2009, Nick Edelen wrote:
> An update to caching mechanism, allowing path names to be cached for blob and
> tree objects. A list of names appearing in each cache slice is appended to the
> end of the slice, which is referenced by variable-sized indexes per entry.
> This allows pack-objects to more intelligently schedule unpacked/poorly packed
> object, and enables proper duplication of rev-list's behaivor.
>
> Signed-off-by: Nick Edelen <sirnot@gmail.com>
[...]
Well, OK. Let's try it out for myself.
I'm applying the whole series on top of current "next" as of now.
Applying the first patch, git-am tells me:
|warning: 70 lines add whitespace errors.
You might want to fix those.
Then build+install. Things still work fine so far. I'm using git's own
git repository. So let's get real:
|$ git rev-cache add --all
|fatal: Unable to create temporary file: Permission denied
Hmmm... why? Not good for a start. Using strace:
|$ strace git rev-cache add --all
[...]
|stat(".git/rev-cache", {st_mode=S_IFDIR|0664, st_size=4096, ...}) = 0
|open(".git/rev-cache/MGhgcp", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
|write(2, "fatal: Unable to create temporary"..., 58) = 58
|exit_group(128) = ?
OK, so attempting .git/rev-cache/MGhgcp fails with EACCES. Let's see:
|$ ls -ld .git/rev-cache/
|drw-rw-r-- 2 nico nico 4096 2009-08-17 22:47 .git/rev-cache/
There is no directory execute permission at all. Indeed, looking at
rev-cache.c line 2314, the mode passed to mkdir() is 0x666. This should
rather be 0777. Which brings the question: how could this ever work for
you? Are you testing your code as root?
|$ chmod +x .git/rev-cache
|$ git]$ git rev-cache add --all
|objects: 115733
|paths: 1535
|62e497619dbb2f8b783c89084054864965bb00d8
|endpoints:
|S 1cae2b588249e8b45239faebc658c7fa45948932
|S 4aec0d2391eb569776e332d9c15b354cd50a64c5
|S 1ff19ffed62bb581cd8eb635fe6e65ffca7ba1d0
|S fcd8ea7a91ad55d094a78c826083ebac149d81e5
|S 181301656f7a1086adcc41c3661551f190635003
|S 2898400a882bfb3c475fc2b53330912edc8a81f8
|S 7c7f2ebdb98f4844347f68b6e64c4968fa7f38e5
|S 1d9d1698ceb7b553f3cb1fdaa3150f0e85ab9cca
|S 348f73cc1db2d7b1412c40eba72319855e2959ff
|S fedc7d5458bd8e2e9589567041228a24a8d7eb4c
|S 0f57bf3ae8f0000de83907f0a674d70a879f7753
|S 7354ca323e31aa2d469498d06feebdcea137e93a
|S d47e28a143f40ad31b88e6d7b9b18bae60d21b01
|S 991ab5ed8769cd1a425b96b92772c89244bc957c
|S 07827905813bce9cadb9db2faac5848a61c7e69f
|S aff6ae5e2f10c4a8e399bf5aa446a58d74444aba
|S 6849908a55d0e7a95fa715310f739cfab4dd8def
|S ac34f56d4cf6a737f7d8cb56a9b57448f8d6e190
|S 740f1f8651561ee3f31d11cde492eedc77272ff1
|S 38b9118536279dd923e7d5c7444f5869b7f709b1
|S 13354f5377d82baee4d8c930df824c8dbeda396d
|S d82c2e2835dd1aca1a0b6b1fc9f6213ad0e0ae9c
|final return value: 0
Good, making progress. By the way, is that output useful? If so, is it
documented somewhere? Surely the "final return value" is probably not
that useful...
Now I want to see how fast rev-list has become.
|$ git rev-list --all --objects > /dev/null
|Segmentation fault
BOOM! :-( And now half of the git commands are just as helpful with
segmentation faults, including 'git log'.
Here's a backtrace from gdb:
|(gdb) bt
|#0 0x0000000000493c33 in to_disked_rc_object_entry (src=0x72d6e0,
| dst=0x7ffff548c034) at rev-cache.c:121
|#1 0x00000000004957f0 in setup_traversal () at rev-cache.c:412
|#2 traverse_cache_slice_1 () at rev-cache.c:487
|#3 traverse_cache_slice (revs=0x7fffffffe010,
| cache_sha1=0x7739b0 "b\227a\235/\213x<\211\b@T\206Ie",
| commit=<value optimized out>, date_so_far=0x0, slop_so_far=0x0,
| queue=0x7fffffffdef8, work=0x7fffffffe010) at rev-cache.c:884
|#4 0x000000000049a4e7 in get_revision_1 (revs=0x7fffffffe010)
| at revision.c:1763
|#5 0x000000000049a55b in get_revision_internal (revs=0x7fffffffe010)
| at revision.c:1886
|#6 0x000000000049a7c1 in get_revision (revs=0x7fffffffe010) at revision.c:1967
|#7 0x00000000004790a7 in traverse_commit_list (revs=0x7fffffffe010,
| show_commit=0x4477d0 <show_commit>, show_object=0x447ba0 <show_object>,
| data=0x7fffffffe3f0) at list-objects.c:164
|#8 0x000000000044808c in cmd_rev_list (argc=1, argv=0x7fffffffe680,
| prefix=0x0) at builtin-rev-list.c:398
|#9 0x0000000000403d13 in run_builtin () at git.c:246
|#10 handle_internal_command (argc=3, argv=0x7fffffffe680) at git.c:391
|#11 0x0000000000403ebd in run_argv () at git.c:433
|#12 main (argc=3, argv=0x7fffffffe680) at git.c:504
Nicolas
^ permalink raw reply
* Re: [PATCH 1/6 (v4)] man page and technical discussion for rev-cache
From: Nicolas Pitre @ 2009-08-18 2:34 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <op.uys3qgmitdk399@sirnot.private>
On Mon, 17 Aug 2009, Nick Edelen wrote:
> diff --git a/Documentation/git-rev-cache.txt b/Documentation/git-rev-cache.txt
> new file mode 100644
> index 0000000..3479499
> --- /dev/null
> +++ b/Documentation/git-rev-cache.txt
[...]
> +add
> +~~~
> +Add revisions to the cache by creating a new cache slice. Reads a revision
> +list from the command line, formatted as: `START START ... \--not END END ...`
> +
> +Options:
> +
> +\--all::
> + Include all refs in the new cache slice, like the \--all option in
> + 'rev-list'.
> +
> +\--fresh::
> + Exclude everything already in the revision cache, analogous to
> + \--incremental in 'pack-objects'.
Why not using --incremental here as wel then?
> +\--stdin::
> + Read newline-seperated revisions from the standard input. Use \--not
> + to exclude commits, as on the command line.
> +
> +\--legs::
> + Ensure newly-generated cache slice has no partial ends. This means that
> + no commit has partially cached parents, in that all its parents are
> + cached or none of them are.
> ++
> +\--legs will cause 'rev-cache' to expand potential slice end-points (creating
> +"legs") until this condition is met, simplifying the cache slice structure.
> +'rev-cache' itself does not care if a slice has legs or not, but the condition
> +may reduce the required complexity of other applications that might use the
> +revision cache.
I'm not sure I understand this. As a user, should I care?
Nicolas
^ permalink raw reply
* Re: [PATCH 09/11] Add MSVC porting header files.
From: Frank Li @ 2009-08-18 2:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908171902300.4991@intel-tinevez-2-302>
>> Add unix head file, dirent.h, unistd.h and time.h
>
> These are copied from somewhere. From where? What is the license?
It comes from msys, which used to build msysgit.
>> Add MSVC special porting head file msvc.h and msvc.c.
>
> This is added by you. Logically, that should be a separate patch.
Okay I will split.
>> +#define NO_MEMMEM
>> +#define NO_C99_FORMAT
>> +#define NO_STRTOUMAX
>> +#define NO_MKDTEMP
>> +#define NO_MKSTEMPS
>> +
>> +#define RUNTIME_PREFIX
>> +#define NO_ST_BLOCKS_IN_STRUCT_STAT
>> +#define NO_NSEC
>> +#define USE_WIN32_MMAP
>> +#define USE_NED_ALLOCATOR
>> +
>> +#define NO_REGEX
>> +
>> +#define NO_SYS_SELECT_H
>> +#define NO_PTHEADS
>> +#define HAVE_STRING_H 1
>> +#define STDC_HEADERS
>> +#define NO_ICONV
>
> These would normally be defined in the Makefile. You might want to state
> that in a comment.
>
> Or maybe move the definitions (along with vsnprintf) to the .vcproj file,
> which is the logical pendant of the Makefile?
I really want to in .vcproj. but the same context needs to copy
DEBUG\RELEASE 32\64bit, libgit.vcproj and git.vcproj. 8 place needs
copy. To avoid copy in vcproj file, I move it hear.
^ permalink raw reply
* Re: [PATCH 07/11] Add O_BINARY flag to open flag at mingw.c
From: Frank Li @ 2009-08-18 2:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908171856290.4991@intel-tinevez-2-302>
> How about this instead?
>
> mingw.c: Use the O_BINARY flag to open files
>
> On Windows, non-text files must be opened using the O_BINARY flag.
> MinGW does this for us automatically, but Microsoft Visual C++
> does not.
>
> Also, Johannes said that this would be a nice cleanup.
>
Okay, Do you need me change commit comments to resubmit patch?
> BTW what about fopen()?
I never found problem at fopen, I will double check it.
>
> Patch is obviously good.
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: [PATCH 08/11] Place __stdcall to correct position.
From: Frank Li @ 2009-08-18 1:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908171859060.4991@intel-tinevez-2-302>
> How about "... to the correct ..." and "MSVC requires _stdcall to be
> between return value..." and "All Win32 API functions are declared with
> the WINAPI attribute."?
WINAPI always like
BOOL WINAPI function_name(xxx);
It compile fail if WINAPI BOOL function_name(xxx);
>> #if defined(__MINGW32__) || defined(_MSC_VER)
>> -static __stdcall unsigned run_thread(void *data)
>> +static unsigned __stdcall run_thread(void *data)
>> {
>> struct async *async = data;
>> return async->proc(async->fd_for_proc, async->data);
>> }
>> -#endif
>> +#endif /* __MINGW32__ || _MSC_VER */
>
> I do not think this is necessary. There are only 5 lines wrapped into
> those #ifdef guards, the developer should be able to see that far.
>
Do you means remove /* __MINGW32__ || _MSC_VER */?
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Nguyen Thai Ngoc Duy @ 2009-08-18 1:43 UTC (permalink / raw)
To: skillzero; +Cc: Jakub Narebski, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <2729632a0908171734p16d6ee7dm5f62848f7625ffbc@mail.gmail.com>
On Tue, Aug 18, 2009 at 7:34 AM, <skillzero@gmail.com> wrote:
> On Mon, Aug 17, 2009 at 5:17 PM, Jakub Narebski<jnareb@gmail.com> wrote:
>
>> There is e.g. question if "git grep" should search "no-checkout" files;
>> in the "assume-unchanged" case it should, I think, search index version.
>
> I would like it to git grep to not search paths outside the sparse
> area (although --no-sparse would be nice for git grep in case you did
> want to search everything). The main reason I want sparse checkouts is
> for performance reasons. For example, git grep can take 10 minutes on
> my full repository so excluding paths outside the sparse area would
> reduce that to a few seconds.
That's a porcelain question that I'd leave it for now. FWIW you can do
something like this:
git ls-files -v|grep '^H'|cut -c 2-|xargs git grep
/me misses "cleartool find"
--
Duy
^ permalink raw reply
* Re: [PATCH 04/11] Add _MSC_VER predefine macro to make same behaviors with __MINGW32__ Enable MSVC build. MSVC have the save behaviors with msysgit.
From: Frank Li @ 2009-08-18 1:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908171835590.4991@intel-tinevez-2-302>
>
> Test whether WIN32 is defined rather than __MINGW32__
I think WIN32 is better, how about 64bit build case?
In 64bit environment, VC define WIN64 not WIN32.
^ permalink raw reply
* Re: [PATCH 03/11] Define SNPRINTF_SIZE_CORR 1 when use MSVC build git
From: Frank Li @ 2009-08-18 1:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908171829510.4991@intel-tinevez-2-302>
> How about this instead?
>
> Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
>
> The Microsoft C runtime's vsnprintf function does not add NUL at
> the end of the buffer.
>
> Further, Microsoft deprecated vsnprintf in favor of _vsnprintf, so
> add a #define to that end.
Of course, do you need me change commit comment and resend patch?
>
> The patch is good, although I suspect that the definition of vsnprintf is
> better handled in the precompiler options in .vcproj.
>
If define in .vcproj, it needs copy that to DEBUG\RELEASE and 32bit\64bit (2x2)
4 places. It is easy to miss one.
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: [msysGit] Re: Using VC build git (split patch)
From: Frank Li @ 2009-08-18 1:07 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git, msysGit, Johannes Schindelin
In-Reply-To: <4A899FDB.8080308@gmail.com>
> Hi Frank,
>
> Could you please also update your repo at repo.or.cz, then it'll be
> easier if anyone wants to help you in the process of streamlining the
> patch series?
>
It seems network problem yesterday, I can't push anything to
repo.or.cz. I will try today.
^ 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