Am 10.08.19 um 05:03 schrieb Carlo Marcelo Arenas Belón:
> Make using a general context (that is only needed with NED) to depend
> on NED being selected at compile time.
A custom general context is needed to convince PCRE2 to use xmalloc()
instead of mallo(). That is independent of the choice of
Am 10.08.19 um 05:05 schrieb Carlo Arenas:
> in macOS (obviously testing without NED) the following is the output
> of (a hacked version) of p7801 for maint (against chromium's
> repository), with René's patch on top
Do you mean p7820? And what did you change? Looking at the results you
removed
Chère,
s'il vous plaît, j'attends toujours de vos nouvelles après vous avoir
envoyé le second message
On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote:
>
> Am 10.08.19 um 05:03 schrieb Carlo Marcelo Arenas Belón:
> > Make using a general context (that is only needed with NED) to depend
> > on NED being selected at compile time.
>
> A custom general context is needed to convince PCRE2 to use xma
Hi,
Git v2.23.0-rc2 has been released, and it's time to start new round of git l10n.
This time there are 4 updated messages need to be translated since last update:
l10n: git.pot: v2.23.0 round 2 (4 new, 6 removed)
Generate po/git.pot from v2.23.0-rc2 for git v2.23.0 l10n round 2.
On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote:
>
> Am 10.08.19 um 05:05 schrieb Carlo Arenas:
> > in macOS (obviously testing without NED) the following is the output
> > of (a hacked version) of p7801 for maint (against chromium's
> > repository), with René's patch on top
>
> Do you mean p7
Hi Carlo,
On Fri, 9 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> diff --git a/grep.c b/grep.c
> index 8255ec956e..233072ed80 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -482,6 +482,7 @@ static void free_pcre1_regexp(struct grep_pat *p)
> #endif /* !USE_LIBPCRE1 */
>
> #ifdef USE_LIBPCRE2
> +#ifd
I tracked down a source of Git corrupting repositories to lock file
design not being robust when containers / PID namespaces are present.
In my case, the corruption stemmed from premature release of the `git
gc` lock in the gc.pid file. But since the lock file code for that file
is in gc.c, there
Hello,
I have been using git-svn tool for SVN to GIT migration. I see issues in
migration of branches/tags located in SVN at different level of hierarchy. To
some extent I can define the layout in config file but it's difficult in few
cases. like https:/svnrepo
a/b/branches/
a/b/c/branches/
a/
Am 10.08.19 um 10:42 schrieb Carlo Arenas:
> On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote:
>>
>> Am 10.08.19 um 05:03 schrieb Carlo Marcelo Arenas Belón:
>>> Make using a general context (that is only needed with NED) to depend
>>> on NED being selected at compile time.
>>
>> A custom gener
I am observing git checkout --patch making changes to the wrong lines of a file.
This is with a clean install of git version 2.20.1 on a debian docker
container (image tag 10.0 which is also "latest" as of this writing).
With a diff that looks like the following:
diff --git a/file.txt b/file.txt
They were disabled at 53b8d93 ("grep: disable threading in non-worktree
case", 12-12-2011), due to observable performance drops. But now that
zlib inflation can be performed in parallel, for some of git-grep's
options, we can regain the speedup.
Grepping 'abcd[02]' ("Regex 1") and '(static|extern)
Allow read_object_file_extended() to be called by multiple threads
protecting it with a lock. The lock usage can be toggled with
enable_obj_read_lock() and disable_obj_read_lock().
Probably there are many spots in read_object_file_extended()'s call
chain that could be executed unlocked (and thus,
This series focuses on allowing parallel access to zlib inflation and
using that to perform a faster git-grep in the non-worktree case.
Threads were disabled for this case at 53b8d93 ("grep: disable
threading in non-worktree case", 12-12-2011), due to performance drops.
However, by allowing threa
git-grep has some internal locks to protect thread-unsafe operations
when running with threads. The usage of these locks can be toggled
through the variable 'grep_use_locks'. However, it's not currently
possible to enable each lock individually. And since object reading has
its own locks now, it is
git-grep uses 'grep_read_mutex' to protect some object reading
operations. But these have their own internal lock now, which ensure a
better performance (with more parallel regions). So, disable the former
when it's possible to use the latter, with enable_obj_read_lock().
Signed-off-by: Matheus Ta
Am 10.08.19 um 14:40 schrieb Carlo Arenas:
> On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote:
>> I don't understand why my performance is lower by factor 2.5 than yours
>> for all perl regex tests except 7820.15 (your 7820.4), where my system
>> is two times faster. Debian Testing, GCC 9.1.0,
4a30976e28 ([PATCH] support older versions of libcurl, 2005-07-28) added
support for conditionally initializing cURL but when f0ed8226c9
(Add custom memory allocator to MinGW and MacOS builds, 2009-05-31) that
support wasn't updated to make sure cURL will use the same allocator than
git if compiled
On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
tested in macOS 10.14.6 with the system provided cURL (7.54.0)
and latest (7.65.3) and while the API used should be added starting around
7.12.0 (mid 2014).
Let me just gently point out that 7.12.0 was relased mid *2004*, see
https://curl
On Sat, Aug 10, 2019 at 3:17 PM Daniel Stenberg wrote:
>
> On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
>
> > tested in macOS 10.14.6 with the system provided cURL (7.54.0)
> > and latest (7.65.3) and while the API used should be added starting around
> > 7.12.0 (mid 2014).
>
> Let me ju
Hi,
I am trying to write an implementation of git clone over ssh and am a little
confused how to determine a server response has ended. Specifically, after a
client sends its requested 'want', the server sends the pack content over.
However, how does the client know to stop reading data? If I r
21 matches
Mail list logo
