Hello all,
On 01/14/2016 09:15 PM, Junio C Hamano wrote:
> Eric Wong writes:
>
>> Error messages should attempt to fit within the confines of
>> an 80-column terminal to avoid compatibility and accessibility
>> problems. Furthermore the word "directories" can be misleading
>> when used in the co
Introduce prefixed globs for branches and tags in git-svn.
Globs like 'release_*' allow users to avoid long lines in config like:
branches = branches/{release_20,release_21,release_22,...}
Signed-off-by: Victor Leschuk
---
Changes from v3:
* Wrapped all test preparations i
Introduce prefixed globs for branches and tags in git-svn.
Globs like 'release_*' allow users to avoid long lines in config like:
branches = branches/{release_20,release_21,release_22,...}
Signed-off-by: Victor Leschuk
---
Changes from v1 (in v2 I forgot to switch
Introduce prefixed globs for branches and tags in git-svn.
Globs like 'release_*' allow users to avoid long lines in config like:
branches = branches/{release_20,release_21,release_22,...}
Signed-off-by: Victor Leschuk
---
Changes from v1:
* Joined implementation and test in
ost things look fine with 1/2, comments
on 2/2 below...
Victor Leschuk wrote:
Add test for git-svn prefixed globs.
Why a separate patch? Unless there's some documentation purpose
for a regression, usually tests and a feature should be added
atomically in the same commit.
--- /dev/null
++
Add test for git-svn prefixed globs.
Signed-off-by: Victor Leschuk
---
t/t9168-git-svn-prefixed-glob.sh | 136 +++
1 file changed, 136 insertions(+)
create mode 100755 t/t9168-git-svn-prefixed-glob.sh
diff --git a/t/t9168-git-svn-prefixed-glob.sh b/t/t9168
Introduce prefixed globs for branches and tags in git-svn.
Signed-off-by: Victor Leschuk
---
Documentation/git-svn.txt | 5 +
perl/Git/SVN/GlobSpec.pm | 9 -
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index
*
instead of this.
Thus I suggest to add support for such 'prefixed' globs into git-svn.
Victor Leschuk (2):
Introduce prefixed globs for branches and tags in git-svn.
Add test for git-svn prefixed globs.
Documentation/git-svn.txt| 5 ++
perl/Git/SVN/GlobSpec.pm
Hello Junio,
On 12/15/2015 11:06 PM, Junio C Hamano wrote:
Victor Leschuk writes:
Subject: Re: [PATCH 1/2] Introduce grep threads param
I'll retitle this to something like
grep: add --threads= option and grep.threads configuration
while queuing (which I did for v7 earlier)
"git grep" can now be configured (or told from the command line)
how many threads to use when searching in the working tree files.
Signed-off-by: Victor Leschuk
---
Documentation/config.txt | 4 +++
Documentation/git-grep.txt | 12 +
buil
single place (grep.threads
description in git-grep.txt) and is referenced from other places. Also made few
language improvements in documentation.
* Style improvements: splitted too long lines
Victor Leschuk (2):
"git grep" can now be configured (or told from the command line)
how m
tiple threads can significantly
boost grep performance when working on slow filesystems (or repo isn't cached)
or through network (for example repo is located on NFS).
Signed-off-by: Victor Leschuk
---
builtin/grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builti
Hello Eric:
Hmm, v7 doesn't seem to address any of the v6 review comments here[1].
Was that review merely overlooked or did you disagree with the
reviewer?
[1]: http://article.gmane.org/gmane.comp.version-control.git/281817
Sorry, it looks like I missed that letter. My bad.
History of change
through network (for example repo is located on NFS).
Signed-off-by: Victor Leschuk
---
History of changes from the first version ($gmane/280053/:
* Param renamed from threads-num to threads
* Short version of '--threads' cmd key was removed
* Made num_thread
Hello all,
does anybody have time to review this patch?
PS Sorry for bothering =)
--
Best Regards,
Victor
From: Victor Leschuk [vlesc...@gmail.com]
Sent: Wednesday, November 11, 2015 03:52
To: git@vger.kernel.org
Cc: Victor Leschuk
Subject: [PATCH v6
On 11/20/2015 05:09 PM, Jeff King wrote:
* vl/grep-configurable-threads (2015-11-01) 1 commit
- grep: add --threads= option and grep.threads configuration
"git grep" can now be configured (or told from the command line)
how many threads to use when searching in the working tree files.
d patch to pu?
Thanks.
--
Best Regards,
Victor
____
From: Victor Leschuk [vlesc...@gmail.com]
Sent: Wednesday, November 11, 2015 03:52
To: git@vger.kernel.org
Cc: Victor Leschuk
Subject: [PATCH v6] Add git-grep threads param
"git grep" can now be conf
ULT (8) threads will be used even on 1-core CPU.
Signed-off-by: Victor Leschuk
---
History of changes from the first version ($gmane/280053/:
* Param renamed from threads-num to threads
* Short version of '--threads' cmd key was removed
* Made num_threads &#x
"git grep" can now be configured (or told from the command line)
how many threads to use when searching in the working tree files.
Signed-off-by: Victor Leschuk
---
Documentation/config.txt | 7 +
Documentation/git-grep.txt | 15 ++
buil
Correct.
I think adding the option (both to command line and to config file) is good, as
long as the IO issues are documented. And default to just the fixed number of
threads for now - and with the option, maybe people can then more easily try
out different scenarios and maybe improve on the p
.
> In the meantime I'd argue for just getting rid of the online_cpu's
> check, because
> (a) I think it's actively misleading
> (b) the threaded grep probably doesn't hurt much even on a single
> CPU, and the _potential_ upside from IO could easily dwarf the cost.
> (c) do developers actual
On Mon, Nov 9, 2015 at 9:28 AM, Victor Leschuk
wrote:
>
> Maybe use the simplest version (and keep num_numbers == 0 also as flag for
> all other checks in code like if(num_flags) ):
>
> if (list.nr || cached )
> num_threads = 0; // do not use threads
> else
> if (list.nr || cached)
>num_threads = 1;
> if (!num_threads)
> num_threads = GREP_NUM_THREADS_DEFAULT;
> and then later, instead of use_threads, do:
> if (num_threads <= 1) {
... do single-threaded version ...
> } else {
... do multi-threaded version ...
> Why don't we leave it at 8, then? That's the conservative choice, and
> once we have --threads, people can easily experiment with different
> values and we can follow-up with a change to the default if need be.
I'd propose the following:
if (list.nr || cached) {
From: Jeff King [p...@peff.net]
Sent: Tuesday, November 03, 2015 22:40
To: Junio C Hamano
Cc: Victor Leschuk; git@vger.kernel.org; Victor Leschuk;
torva...@linux-foundation.org; j...@keeping.me.uk
Subject: Re: [PATCH v4] Add git-grep threads param
On Tue
>> do we have any objections on this patch?
> The question you should be asking is "do we have any support".
Hello all, CCing participated reviewers. As Junio has correctly mentioned: "Do
we have any support for including this functionality?"
I think this kind of customization can be useful in
Hello all,
do we have any objections on this patch?
--
Best Regards,
Victor
From: Victor Leschuk [vlesc...@gmail.com]
Sent: Tuesday, October 27, 2015 14:22
To: git@vger.kernel.org
Cc: Victor Leschuk
Subject: [PATCH v4] Add git-grep threads param
Make
> > +if test -n "$TEST_GDB_GIT"
> > +then
> > + exec gdb -args "${GIT_EXEC_PATH}/@@PROG@@" "$@"
> Maybe we could make $TEST_GDB_GIT not just a boolean flag? It would be useful
> to contain "gdb" executable name. It would allow to set path to GDB when it
> is not in $PATH, set different debugg
+if test -n "$TEST_GDB_GIT"
+then
+ exec gdb -args "${GIT_EXEC_PATH}/@@PROG@@" "$@"
Maybe we could make $TEST_GDB_GIT not just a boolean flag? It would be
useful to contain "gdb" executable name. It would allow to set path to
GDB when it is not in $PATH, set different debuggers (for e
On 10/28/2015 04:35 PM, Mathias L. Baumann wrote:
I was using the latest git version 2.6.2 already.
I suspect it is due to a .gitconfig. This is what is probably required:
➜ ~ cat .gitconfig
[diff]
submodule = log
Yep, that did the trick.
The segfault is from
sha1_file.c:
/* add the
On 10/28/2015 02:58 PM, Mathias L. Baumann wrote:
Hello dear git devs,
I just stumbled upon a segfault when doing just "git diff" in my repo.
I managed to create a minimal repo setup where the bug is reproducable.
The problem seems to be a mix of having an untracked submodule and
having set
Make number of git-grep worker threads a configuration parameter.
According to several tests on systems with different number of CPU cores
the hard-coded number of 8 threads is not optimal for all systems:
tuning this parameter can significantly speed up grep performance.
Signed-off-by: Victor
Hello John,
>> This thought also crossed my mind, however we already pass grep_opt to
>> start_threads() function, so I think passing it to wait_all() is not
>> that ugly, and kind of symmetric. And I do not like the idea of
>> duplicating same information in different places. What do you think?
Hello Linus,
>> According to several tests on systems with different number of CPU cores
>> the hard-coded number of 8 threads is not optimal for all systems:
> Did you also compare cold-cache filesystem performance?
> One of the reasons for doing threaded grep is for CPU scaling. But another
Hello John,
see comments inline.
>> @@ -22,6 +22,7 @@ SYNOPSIS
>> [--color[=] | --no-color]
>> [--break] [--heading] [-p | --show-function]
>> [-A ] [-B ] [-C ]
>> +[--threads ]
> Is this the best place for this option? I know the current list isn't
> sorted i
Make number of git-grep worker threads a configuration parameter.
According to several tests on systems with different number of CPU cores
the hard-coded number of 8 threads is not optimal for all systems:
tuning this parameter can significantly speed up grep performance.
Signed-off-by: Victor
Hello Noam,
The problem is that in the absence of explicit argument we set the list
of files to special path ":/" which means repo root:
if ((0 < addremove_explicit || take_worktree_changes) && !argc) {
static const char *whole[2] = { ":/", NULL };
argc = 1;
argv =
s:
on my 4-core and 8-core systems the thread number of 4 worked about 20% faster
than
default 8. So I think it is better to allow users tune this parameter.
Signed-off-by: Victor Leschuk
---
Documentation/config.txt | 4
Documentation/git-grep.txt | 4
rsday, October 22, 2015 7:23 AM
To: Victor Leschuk
Cc: git@vger.kernel.org; Victor Leschuk
Subject: Re: [PATCH] Add git-grep threads-num param
On Thu, Oct 22, 2015 at 04:23:56PM +0300, Victor Leschuk wrote:
> Hello all, I suggest we make number of git-grep worker threads a configuration
> parame
of 4 worked about 20% faster
than
default 8. So I think it is better to allow users tune this parameter.
Signed-off-by: Victor Leschuk
---
Documentation/config.txt | 4
Documentation/git-grep.txt | 5 +
builtin/grep.c | 20
Hamano
[gits...@pobox.com]
Sent: Monday, October 12, 2015 10:55 AM
To: Victor Leschuk
Cc: git@vger.kernel.org; vlesc...@gmail.com
Subject: Re: thread-utils: build with NO_PTHREADS fails
Junio C Hamano writes:
> Victor Leschuk writes:
>
>> I think that no one tried it for a long time
Hello all,
I think that no one tried it for a long time but I needed a single-threaded git
version for debug purpose. I tried to build with -DNO_PTHREADS and
thread-utils.c failed to compile.
In brief the situation is the following:
in header file we have something like that:
#ifndef NO_PTHR
ds,
Victor
From: Eric Wong [normalper...@yhbt.net]
Sent: Wednesday, September 23, 2015 12:22 PM
To: Victor Leschuk
Cc: Junio C Hamano; git@vger.kernel.org
Subject: Re: [PATCH] git-svn: make batch mode optional for git-cat-file
Victor Leschuk wrote:
> Hello Eric, thank
ide
git-cat-file, I think we could give it a try, I can prepare a patch and run
some tests.
--
Best Regards,
Victor
________
From: Eric Wong [normalper...@yhbt.net]
Sent: Tuesday, September 22, 2015 5:35 PM
To: Victor Leschuk
Cc: Junio C Hamano; git@vger.kernel.org
Subject: Re: [PATCH] git-svn: ma
x27;. So I was just following the existing convention. Do you think
we need to change it and stick with --catch-file-batch=1/--cat-file-batch=0 ?
--
Best Regards,
Victor
________
From: Victor Leschuk
Sent: Monday, September 21, 2015 3:03 PM
To: Junio C Hamano
Cc
Hello all,
I've been playing with git-svn for some time already and as it seems to me
there are two most important problems which make it hard to use in production
for large repositories. Very low speed and large memory footprint of
synchronization with SVN repos (I am talking about clone and
__
From: Junio C Hamano [jch2...@gmail.com] On Behalf Of Junio C Hamano
[gits...@pobox.com]
Sent: Monday, September 21, 2015 11:25 AM
To: Victor Leschuk
Cc: git@vger.kernel.org; Victor Leschuk
Subject: Re: [PATCH] git-svn: make batch mode optional for git-cat-file
Victor Leschu
Signed-off-by: Victor Leschuk
---
git-svn.perl | 1 +
perl/Git.pm | 41 -
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/git-svn.perl b/git-svn.perl
index 36f7240..b793c26 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -139,6 +139,7
--
Best Regards,
Victor
From: Jeff King [p...@peff.net]
Sent: Wednesday, September 16, 2015 4:56 AM
To: Victor Leschuk
Cc: git@vger.kernel.org
Subject: Re: git-svn: cat-file memory usage
On Wed, Sep 16, 2015 at 04:00:48AM -0700, Victor Leschuk wrote:
&
or somehow tune allocation policy in C code?
Please let me know your thoughts.
--
Best Regards,
Victor Leschuk
50 matches
Mail list logo
