[PATCH 1/1] mingw: initialize HOME on startup

From: Karsten Blees HOME initialization was historically duplicated in many different places, including /etc/profile, launch scripts such as git-bash.vbs and gitk.cmd, and (although slightly broken) in the git-wrapper. Even unrelated projects such as GitExtensions and TortoiseGit need to

[PATCH v2 1/1] gettext: always use UTF-8 on native Windows

From: Karsten Blees On native Windows, Git exclusively uses UTF-8 for console output (both with MinTTY and native Win32 Console). Gettext uses `setlocale()` to determine the output encoding for translated text, however, MSVCRT's `setlocale()` does not support UTF-8. As a result, translated

[PATCH 1/1] gettext: always use UTF-8 on native Windows

From: Karsten Blees Git on native Windows exclusively uses UTF-8 for console output (both with MinTTY and native Console windows). Gettext uses setlocale() to determine the output encoding for translated text, however, MSVCRT's setlocale() doesn't support UTF-8. As a result, translat

[PATCH 2/3] mingw: replace MSVCRT's fstat() with a Win32-based implementation

From: Karsten Blees fstat() is the only stat-related CRT function for which we don't have a full replacement yet (and thus the only reason to stick with MSVCRT's 'struct stat' definition). Fully implement fstat(), in preparation of implementing a POSIX 2013 compatibl

[PATCH 3/3] mingw: implement nanosecond-precision file times

From: Karsten Blees We no longer use any of MSVCRT's stat-functions, so there's no need to stick to a CRT-compatible 'struct stat' either. Define and use our own POSIX-2013-compatible 'struct stat' with nanosecond- precision file times. Note: This can cause per

Re: [PATCH v2] hashmap API: introduce for_each_hashmap_entry() helper macro

Am 17.03.2016 um 11:38 schrieb Alexander Kuleshov: > This patch introduces the for_each_hashmap_entry() macro for more I'd rather call it 'hashmap_for_each', following the pattern 'operandtype_operation' used throughout git. E.g. we already have 'hashmap_get', not 'get_hashmap_entry'. I realize

Re: [RFC PATCH] hashmap API: introduce for_each_hashmap_entry() helper macro

Am 16.03.2016 um 17:39 schrieb Alexander Kuleshov: > There is common pattern to traverse a hashmap in git source code: > > hashmap_iter_init(map, &iter); > while ((entry = hashmap_iter_next(&iter))) > // do something with entry > The hashmap_iter_first() function al

Re: broken racy detection and performance issues with nanosecond file times

Am 28.09.2015 um 19:38 schrieb Junio C Hamano: > Karsten Blees writes: > >> Problem 1: Failure to detect racy files (without USE_NSEC) >> == >> >> Git may not detect racy changes when 'update-index'

Re: [PATCH/RFC] read-cache: fix file time comparisons with different precisions

Am 28.09.2015 um 14:52 schrieb Johannes Schindelin: > Otherwise there would be that little loop-hole where (nsec % 1000) == 0 *by > chance* and we assume the timestamps to be identical even if they are not. Yeah, but in this case the file would be racy, as racy-checks use the same comparison now.

[PATCH/RFC] read-cache: fix file time comparisons with different precisions

fixes racy detection in USE_NSEC-enabled git with core.checkStat=minimal, as the coreStat setting now affects racy checks as well. Finally, do not check ctime if ctime.sec is 0 (as recorded by JGit). Signed-off-by: Karsten Blees --- read-ca

broken racy detection and performance issues with nanosecond file times

Hi there, I think I found a few nasty problems with racy detection, as well as performance issues when using git implementations with different file time resolutions on the same repository (e.g. git compiled with and without USE_NSEC, libgit2 compiled with and without USE_NSEC, JGit executed in di

Re: Git doesn't detect change, if file modification time is restored to original one

Am 23.07.2015 um 16:53 schrieb Konstantin Khomoutov: > On Thu, 23 Jul 2015 11:14:11 +0200 > Konrád Lőrinczi wrote: > > [...] >> I accept these solutions as workarounds, but the real solution would >> be: Dev suggestions: >> 1) Add a --force-reread option to git status, so user can force >> reread

[PATCH v2] Documentation/i18n.txt: clarify character encoding support

established UTF-8 NFC as de-facto standard for path names. Update the documentation in i18n.txt to reflect the current status-quo. Signed-off-by: Karsten Blees --- Sorry for the delay, got swamped with other stuff... Am 17.06.2015 um 22:45 schrieb Junio C Hamano: > > ... I am OK to

[PATCH v2] Makefile / racy-git.txt: clarify USE_NSEC prerequisites

Signed-off-by: Karsten Blees --- ...just changed wording as you suggested. Documentation/technical/racy-git.txt | 8 ++-- Makefile | 9 + 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/Documentation/technical/racy-git.txt b

[PATCH] config.c: fix writing config files on Windows network shares

Renaming to an existing file doesn't work on Windows network shares if the target file is open. munmap() the old config file before commit_lock_file. Signed-off-by: Karsten Blees --- See https://github.com/git-for-windows/git/issues/226 Strangely, renaming to an open file works fine on

Re: [PATCH] Documentation/i18n.txt: clarify character encoding support

Am 15.06.2015 um 02:12 schrieb Junio C Hamano: > Karsten Blees writes: > >> diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt >> index e9a1d5d..e5f6233 100644 >> --- a/Documentation/i18n.txt >> +++ b/Documentation/i18n.txt >> @@ -1,18 +1,28 @@ >

[PATCH] Makefile / racy-git.txt: clarify USE_NSEC prerequisites

Signed-off-by: Karsten Blees --- Enabling nanosecond file times was recently discussed on the libgit2 project, so I thought its time to fix the nanosecond issue on Linux. Don't know yet if the patch will be accepted (and in which kernel version). Considering that nanosecond file times are

[PATCH] Documentation/i18n.txt: clarify character encoding support

established UTF-8 NFC as de-facto standard for path names. Update the documentation in i18n.txt to reflect the current status-quo. Signed-off-by: Karsten Blees --- Documentation/i18n.txt | 30 -- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/Docu

[PATCH (resend)] git-gui: make gc warning threshold match 'git gc --auto'

very small, to get a better estimate. Signed-off-by: Karsten Blees --- git-gui/lib/database.tcl | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/git-gui/lib/database.tcl b/git-gui/lib/database.tcl index 1f187ed..212b195 100644 --- a/git-gui/lib/database.tcl ++

Re: [PATCH] git-new-workdir: add windows compatibility

Am 26.05.2015 um 06:03 schrieb Junio C Hamano: > Daniel Smith writes: > >> When running on Windows in MinGW, creating symbolic links via ln always >> failed. >> >> Using mklink instead of ln is the recommended method of creating links on >> Windows: >> http://stackoverflow.com/questions/18641864/

Re: [PATCH v2 0/4] UTF8 BOM follow-up

Am 16.04.2015 um 20:39 schrieb Junio C Hamano: > This is on top of the ".gitignore can start with UTF8 BOM" patch > from Carlos. > > Second try; the first patch is new to clarify the logic in the > codeflow after Carlos's patch, and the second one has been adjusted > accordingly. > > Junio C Hama

Re: [PATCH 0/3] Win32: nanosecond-precision file times

Am 16.02.2015 um 23:10 schrieb Junio C Hamano: > Karsten Blees writes: > >> However, the Makefile has this to say on the subject: >> >> # Define USE_NSEC below if you want git to care about sub-second file mtimes >> # and ctimes. Note that you need recent glibc

Re: [PATCH 0/3] Win32: nanosecond-precision file times

Am 13.02.2015 um 20:28 schrieb Junio C Hamano: > Karsten Blees writes: > >> Am 13.02.2015 um 00:38 schrieb Junio C Hamano: >>> >>> We do have sec/nsec fields in cache_time structure, so I have >>> nothing against updating the msysGit port to fill that

Re: [PATCH 0/3] Win32: nanosecond-precision file times

Am 13.02.2015 um 00:38 schrieb Junio C Hamano: > Karsten Blees writes: > >> This is more about copying 'old' things around, which usually also >> copies mtime on Windows. E.g.: >> >> # create two files with slightly different mtime >>

Re: [PATCH 3/3] Win32: implement nanosecond-precision file times

Am 13.02.2015 um 00:15 schrieb Thomas Braun: > Am 12.02.2015 um 00:53 schrieb Karsten Blees: >> diff --git a/config.mak.uname b/config.mak.uname >> index b64b63c..a18a4cc 100644 >> --- a/config.mak.uname >> +++ b/config.mak.uname >> @@ -346,7 +

Re: [PATCH 0/3] Win32: nanosecond-precision file times

Am 12.02.2015 um 20:48 schrieb Junio C Hamano: > Karsten Blees writes: > >> However, some users have expressed concerns that 'same size and >> mtime' [2] may theoretically happen by chance in daily operation. > > Hmph. > > Haven't we already ac

[PATCH 3/3] Win32: implement nanosecond-precision file times

We no longer use any of MSVCRT's stat-functions, so there's no need to stick to a CRT-compatible 'struct stat' either. Define and use our own POSIX-2013-compatible 'struct stat' with nanosecond- precision file times. Signed-off-by: Karsten Blees --- compat/mingw

[PATCH 2/3] Win32: replace MSVCRT's fstat() with a Win32-based implementation

with nanosecond-precision file times. Signed-off-by: Karsten Blees --- compat/mingw.c | 28 +++- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/compat/mingw.c b/compat/mingw.c index ba3cfb0..6d73a3d 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -532,28

[PATCH 1/3] Win32: make FILETIME conversion functions public

Signed-off-by: Karsten Blees --- compat/mingw.c | 16 compat/mingw.h | 16 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/compat/mingw.c b/compat/mingw.c index 70f3191..ba3cfb0 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -419,22 +419,6

[PATCH 0/3] Win32: nanosecond-precision file times

pec' file times to make this practically impossible, at least on NTFS with 100ns file time resolution. Cheers, Karsten [1] https://github.com/msysgit/git/issues/312 [2] Note that st_ctime of a file never changes on Windows, as it means 'creation time' rather than 'cha

Re: [PATCH 8/9] autoconf: Check for timer_settime

Am 29.08.2014 19:40, schrieb Keller, Jacob E: > On Fri, 2014-08-29 at 19:26 +0200, Johannes Sixt wrote: >> Am 29.08.2014 18:42, schrieb Jacob Keller: >>> From: Jonas 'Sortie' Termansen >>> >>> This function will be used in a following commit. >>> >>> The timer_settime function is provided in librt

Re: Location of git config on Windows

Am 18.08.2014 00:01, schrieb Erik Faye-Lund: > On Sun, Aug 17, 2014 at 10:18 PM, Daniel Corbe wrote: >> >> I installed git on my Windows machine while it was connected to my >> corporate network. It picked up on that fact and used a mapped drive to >> store its configuration file. >> >> As a resu

Re: Git for Windows 1.9.4.msysgit.1

Am 15.08.2014 19:14, schrieb Thomas Braun: > Hi, > > the Git for Windows team just released the second maintenance release of > the Windows-specific installers for git 1.9.4. > Thank you so much! > Regressions > > git svn is/might be broken. Fixes welcome. rebase -b 0x6400 bin/libsvn

Re: [PATCH] pack-bitmap: do not use gcc packed attribute

Am 05.08.2014 20:47, schrieb Jeff King: > On Mon, Aug 04, 2014 at 09:19:46PM +0200, Karsten Blees wrote: > >> Hmm, I wonder if it wouldn't be simpler to read / write the desired on-disk >> structure directly, without copying to a uchar[6] first. > > Probably. M

[PATCH] git-gui: make gc warning threshold match 'git gc --auto'

t only warns if 'git gc --auto' would also do an automatic gc, i.e.: - calculate the threshold from the gc.auto setting (default 6700, disabled if <= 0) - check directory .git/objects/17 We still check four directories (14-17) if gc.auto is very small, to get a better estimate.

Re: struct hashmap_entry packing

Am 02.08.2014 00:37, schrieb Jeff King: > On Tue, Jul 29, 2014 at 10:40:12PM +0200, Karsten Blees wrote: > >>> The sizeof() has to be the same regardless of whether the hashmap_entry >>> is standalone or in another struct, and therefore must be padded up to >>> 1

Re: [PATCH] pack-bitmap: do not use gcc packed attribute

t have similar functions to read uint8/32 in a stream-based fashion? This raises the question why we read via mmap at all (without munmap()ing the file when done...). We copy all data into internal data structures anyway. Is an fopen/fread-based solution (with fread_u8/_u32 helpers) that much slowe

Re: struct hashmap_entry packing

Am 28.07.2014 19:17, schrieb Jeff King: > Hi Karsten, > > The hashmap_entry documentation claims: > > `struct hashmap_entry`:: > > An opaque structure representing an entry in the hash table, > which must be used as first member of user data structures. > Ideally it should be

Re: "error: Tweaking file descriptors doesn't work with this MSVCRT.dll" on wine

Am 28.07.2014 12:39, schrieb Duy Nguyen: > I know wine is kind of second citizen but is there a cheap trick to > make it work on wine? Reverting fcd428f (Win32: fix broken pipe > detection - 2012-03-01) could result in conflicts in compat that I'm > not comfortable resolving. I don't have Windows a

[RFC/PATCH] Windows tests: let $TRASH_DIRECTORY point to native Windows path

x27; interprets everything before ':' as hostname, not as drive letter. Change respective tests to use stdin / stdout instead of '-f'. Also use $TAR from GIT-BUILD-OPTIONS rather than hardcoded tar. Signed-off-by: Karsten Blees --- Am 25.07.2014 14:30, schrieb Duy Nguyen: > On

Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)

Am 22.07.2014 23:44, schrieb Junio C Hamano: > > * sk/mingw-uni-fix-more (2014-07-21) 14 commits > - Win32: enable color output in Windows cmd.exe > - Win32: patch Windows environment on startup > - Win32: keep the environment sorted > - Win32: use low-level memory allocation during initializa

Re: Bug in get_pwd_cwd() in Windows?

Am 23.07.2014 13:53, schrieb Duy Nguyen: > On Wed, Jul 23, 2014 at 2:35 AM, René Scharfe wrote: >> Am 21.07.2014 16:13, schrieb Duy Nguyen: >> >>> This function tests if $PWD is the same as getcwd() using st_dev and >>> st_ino. But on Windows these fields are always zero >>> (mingw.c:do_lstat). If

Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()

Am 18.07.2014 12:49, schrieb Duy Nguyen: > can be used, else we fall back to chdir. I think there are only four > places that follow this pattern, here, setup.c (.git discovery), git.c > (restore_env) and unix-socket.c. Enough call sites to make it worth > the effort? > real_path(): here we actua

Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()

Am 18.07.2014 13:32, schrieb René Scharfe: > Am 18.07.2014 01:03, schrieb Karsten Blees: >> Am 17.07.2014 19:05, schrieb René Scharfe: >>> Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy: >> [...] >>> "These routines have traditionally been used by prog

[PATCH] t0110/MinGW: skip tests that pass arbitrary bytes on the command line

On Windows, the command line is a Unicode string, it is not possible to pass arbitrary bytes to a program. Disable tests that try to do so. Signed-off-by: Karsten Blees --- t/t0110-urlmatch-normalization.sh | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/t/t0110

[PATCH] fixup! Win32: Unicode environment (outgoing)

compat/mingw.c needs to #include "cache.h" for ALLOC_GROW. Signed-off-by: Karsten Blees --- compat/mingw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/compat/mingw.c b/compat/mingw.c index bd45950..c725a3e 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -4,6 +4,7 @@

Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()

Am 17.07.2014 19:05, schrieb René Scharfe: > Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy: [...] > "These routines have traditionally been used by programs to save the > name of a working directory for the purpose of returning to it. A much > faster and less error-prone method of accomplishing

Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()

Am 17.07.2014 20:03, schrieb Junio C Hamano: > Nguyễn Thái Ngọc Duy writes: > >> This array 'cwd' is used to store the result from getcwd() and chdir() >> back. PATH_MAX is the right constant for the job. On systems with >> longer PATH_MAX (eg. 4096 on Linux), hard coding 1024 fails stuff, >> e.

Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()

Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy: > e.g. "git init". Make it static too to reduce stack usage. But wouldn't this increase overall memory usage? Stack memory will be reused by subsequent code, while static memory cannot be reused (but still increases the process working set). -- T

Re: [PATCH 1/6] MinGW: Skip test redirecting to fd 4

Am 17.07.2014 20:41, schrieb Junio C Hamano: > Stepan Kasal writes: > >> From: Johannes Schindelin >> >> ... because that does not work in MinGW. >> >> Signed-off-by: Johannes Schindelin >> Signed-off-by: Stepan Kasal >> --- >> t/t0081-line-buffer.sh | 2 +- >> 1 file changed, 1 insertion(+),

Re: [PATCH 00/13] mingw unicode environment

Am 17.07.2014 21:00, schrieb Stepan Kasal: > Hi, > >> Karsten Blees writes: >>> I believe we prefer moving code to the right place over forward >>> declarations (IIRC I got bashed for the latter in one of the first rounds >>> of this patch series)

Re: [PATCH 2/6] Disable t0110's high-bit test on Windows

Am 17.07.2014 17:37, schrieb Stepan Kasal: > From: Johannes Schindelin > > The bash Git for Windows uses (i.e. the MSys bash) cannot pass > command-line arguments with high bits set verbatim to non-MSys programs, > but instead converts those characters with high bits set to their hex > representa

Re: [PATCH 00/13] mingw unicode environment

Am 17.07.2014 17:37, schrieb Stepan Kasal: > Hello, > > this is the remainder of Karsten's unicode branch, that is a time > proven part of msysGit. (If this code is accepted, only one patch > would only remain: gitk and git-gui fixes.) > Thank you so much! I had to add '#include "../cache.h"'

Re: [PATCH 2/2] config: use chmod() instead of fchmod()

Am 17.07.2014 00:16, schrieb Junio C Hamano: > Karsten Blees writes: > >> There is no fchmod() on native Windows platforms (MinGW and MSVC), and the >> equivalent Win32 API (SetFileInformationByHandle) requires Windows Vista. >> >> Use chmod() instead. >

Re: [PATCH 2/2] config: use chmod() instead of fchmod()

Am 16.07.2014 07:33, schrieb Johannes Sixt: > Am 16.07.2014 00:54, schrieb Karsten Blees: >> There is no fchmod() on native Windows platforms (MinGW and MSVC), and the >> equivalent Win32 API (SetFileInformationByHandle) requires Windows Vista. >> >> Use chmod() i

Re: [PATCH 1/2] MinGW: fix compile error due to missing ELOOP

Am 16.07.2014 01:42, schrieb Jonathan Nieder: > Karsten Blees wrote: > >> MinGW and MSVC before 2010 don't define ELOOP, use EMLINK (aka "Too many >> links") instead. > [...] >> +#ifndef ELOOP >> +#define ELOOP EMLINK >> +#endif > >

[PATCH 2/2] config: use chmod() instead of fchmod()

There is no fchmod() on native Windows platforms (MinGW and MSVC), and the equivalent Win32 API (SetFileInformationByHandle) requires Windows Vista. Use chmod() instead. Signed-off-by: Karsten Blees --- config.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a

[PATCH 1/2] MinGW: fix compile error due to missing ELOOP

MinGW and MSVC before 2010 don't define ELOOP, use EMLINK (aka "Too many links") instead. Signed-off-by: Karsten Blees --- compat/mingw.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/compat/mingw.h b/compat/mingw.h index 405c08f..510530c 100644 --- a/compat/mingw

Re: [PATCH 0/3] fix test suite with mingw-unicode patches

imilar cases: the commit msg is passed through stdin. >> >> If there are still problems remaining, please tell us. >> >> Thanks, >> Stepan >> >> Karsten Blees (2): >> Win32: Unicode file name support (except dirent) >> Win32: Unicode fi

Re: [PATCH v1 1/3] dir.c: coding style fix

Am 15.07.2014 00:30, schrieb Junio C Hamano: > Karsten Blees writes: > >> From: =?UTF-8?q?Nguy=E1=BB=85n=20Th=C3=A1i=20Ng=E1=BB=8Dc=20Duy?= >> >> >> Signed-off-by: Nguyễn Thái Ngọc Duy >> Signed-off-by: Karsten Blees >> --- > > Thanks for fo

Re: No fchmod() under msygit - Was: Re: [PATCH 00/14] Add submodule test harness

Am 09.07.2014 22:00, schrieb Eric Wong: > Torsten Bögershausen wrote: >> (And why is it "& 0" and not "& 0777") > > This is to preserve the uncommon sticky/sgid/suid bits. Probably not > needed, but better to keep as much intact as possible. > >> Can we avoid the fchmod() all together ?

[PATCH v1 3/3] prep_exclude: remove the artificial PATH_MAX limit

if it gets ENAMETOOLONG. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Karsten Blees --- dir.c | 47 --- dir.h | 2 +- 2 files changed, 29 insertions(+), 20 deletions(-) diff --git a/dir.c b/dir.c index 3068ca8..fcb6872 100644 --- a/dir.c +++ b

[PATCH v1 2/3] dir.h: move struct exclude declaration to top level

From: =?UTF-8?q?Nguy=E1=BB=85n=20Th=C3=A1i=20Ng=E1=BB=8Dc=20Duy?= There is no actual nested struct here. Move it out for clarity. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Karsten Blees --- dir.h | 42 ++ 1 file changed, 22 insertions(+), 20

[PATCH v1 1/3] dir.c: coding style fix

From: =?UTF-8?q?Nguy=E1=BB=85n=20Th=C3=A1i=20Ng=E1=BB=8Dc=20Duy?= Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Karsten Blees --- dir.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/dir.c b/dir.c index e65888d..3068ca8 100644 --- a/dir.c +++ b/dir.c

[PATCH v1 0/3] dir.[ch]: remove PATH_MAX limitation

As discussed in [1], here's the first three patches of Duy's untracked cache series, which fixes a segfault with long paths on Windows. [1] http://article.gmane.org/gmane.comp.version-control.msysgit/20702 Nguyễn Thái Ngọc Duy (3): dir.c: coding style fix dir.h: move struct exclude declarati

[PATCH v8 17/17] api-trace.txt: add trace API documentation

Signed-off-by: Karsten Blees --- Documentation/technical/api-trace.txt | 97 +++ 1 file changed, 97 insertions(+) create mode 100644 Documentation/technical/api-trace.txt diff --git a/Documentation/technical/api-trace.txt b/Documentation/technical/api-trace.txt

[PATCH v8 16/17] progress: simplify performance measurement by using getnanotime()

-by: Karsten Blees Signed-off-by: Junio C Hamano --- progress.c | 71 +++--- 1 file changed, 36 insertions(+), 35 deletions(-) diff --git a/progress.c b/progress.c index 261314e..412e6b1 100644 --- a/progress.c +++ b/progress.c @@ -12,13

[PATCH v8 15/17] wt-status: simplify performance measurement by using getnanotime()

Calculating duration from a single uint64_t is simpler than from a struct timeval. Change performance measurement for 'advice.statusuoption' from gettimeofday() to getnanotime(). Also initialize t_begin to prevent uninitialized variable warning. Signed-off-by: Karsten Blees Signed-off

[PATCH v8 14/17] git: add performance tracing for git's main() function to debug scripts

7 s: git command: 'git' 'config' '--get-color' 'color.interactive.help' 'red bold' 23:57:38.650465 trace.c:405 performance: 0.000243063 s: git command: 'git' 'config' '--get-color' '' 'reset' 23:57:3

[PATCH v8 13/17] trace: add trace_performance facility to debug performance issues

/* ignore */ } trace_performance(t, "frotz"); Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- trace.c | 47 +++ trace.h | 18 ++ 2 files changed, 65 insertions(+) diff --git a/trace.c b/trace.c index b9d7272..af64dbb 100644

[PATCH v8 12/17] trace: add high resolution timer function to debug performance issues

h_absolute_time + mach_timebase_info Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- Makefile | 7 + config.mak.uname | 1 + trace.c | 82 trace.h | 1 + 4 files changed, 91 insertions(+) diff --g

[PATCH v8 10/17] trace: move code around, in preparation to file:line output

No functional changes, just move stuff around so that the next patch isn't that ugly... Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- trace.c | 36 ++-- trace.h | 12 2 files changed, 26 insertions(+), 22 deletions(-) diff --

[PATCH v8 11/17] trace: add 'file:line' to all trace output

er (currently there are 30 *.c files of length 18 and just 11 of 19). Trace output from longer source files (e.g. builtin/receive-pack.c) will not be aligned. Signed-off-by: Karsten Blees --- git-compat-util.h | 4 trace.c | 72 +

[PATCH v8 08/17] trace: disable additional trace output for unit tests

Some unit-tests use trace output to verify internal state, and unstable output such as timestamps and line numbers are not useful there. Disable additional trace output if GIT_TRACE_BARE is set. Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- t/test-lib.sh | 4 trace.c

[PATCH v8 09/17] trace: add current timestamp to all trace output

processes are involved). Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- trace.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/trace.c b/trace.c index a194b16..18e5d93 100644 --- a/trace.c +++ b/trace.c @@ -88,6 +88,9 @@ static const char err_msg

[PATCH v8 06/17] sha1_file: change GIT_TRACE_PACK_ACCESS logging to use trace API

This changes GIT_TRACE_PACK_ACCESS functionality as follows: * supports the same options as GIT_TRACE (e.g. printing to stderr) * no longer supports relative paths * appends to the trace file rather than overwriting Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano

[PATCH v8 07/17] trace: add infrastructure to augment trace output with additional info

an print arbitrary binary data (without barfing on '%' or stopping at '\0'), so 'data' seems more appropriate. Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- trace.c | 47 +-- trace.h | 2 +- 2 files chan

[PATCH v8 05/17] Documentation/git.txt: improve documentation of 'GIT_TRACE*' variables

Separate GIT_TRACE description into what it prints and how to configure where trace output is printed to. Change other GIT_TRACE_* descriptions to refer to GIT_TRACE. Add descriptions for GIT_TRACE_SETUP and GIT_TRACE_SHALLOW. Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano

[PATCH v8 04/17] trace: improve trace performance

use a static 'struct trace_key' instead of a string constant. In trace.c::get_trace_fd(), save and reuse the file descriptor in 'struct trace_key'. Add a 'trace_disable()' API, so that packet_trace() can cleanly disable tracing when it encounters packed data (instead o

[PATCH v8 03/17] trace: remove redundant printf format attribute

trace_printf_key() is the only non-static function that duplicates the printf format attribute in the .c file, remove it for consistency. Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- trace.c | 1 - 1 file changed, 1 deletion(-) diff --git a/trace.c b/trace.c index 37a7fa9

[PATCH v8 02/17] trace: consistently name the format parameter

The format parameter to trace_printf functions is sometimes abbreviated 'fmt'. Rename to 'format' everywhere (consistent with POSIX' printf specification). Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- trace.c | 22 +++--- trace.h |

[PATCH v8 01/17] trace: move trace declarations from cache.h to new trace.h

Also include direct dependencies (strbuf.h and git-compat-util.h for __attribute__) so that trace.h can be used independently of cache.h, e.g. in test programs. Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano --- cache.h | 13 ++--- trace.h | 17 + 2 files

[PATCH v8 00/17] add performance tracing facility

Changes since v7: [04]: Fixed -Wextra compiler warnings, thanks to Ramsay Jones. [11]: Added #ifndef TRACE_CONTEXT, explained why __FILE__ ":" __FUNCTION__ doesn't work. [17]: New Documentation/technical/api-trace.txt Karsten Blees (17): trace: move trace declarations from

Re: [PATCH 2/2] dir: remove PATH_MAX limitation

Am 12.07.2014 00:29, schrieb Junio C Hamano: > Karsten Blees writes: > >> Anyways, I'd like to kindly withdraw this patch in favor of Duy's version. >> >> http://article.gmane.org/gmane.comp.version-control.git/248310 > > Thanks; I've already rever

[PATCH] fixup! symlinks: remove PATH_MAX limitation

Rename cache_def_free to cache_def_clear as it doesn't free the struct cache_def, but just clears its content. Signed-off-by: Karsten Blees --- cache.h | 2 +- preload-index.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cache.h b/cache.h index 44aa439..37

Re: Topic sk/mingw-unicode-spawn-args breaks tests

Am 10.07.2014 22:05, schrieb Johannes Sixt: > It looks like I totally missed the topic sk/mingw-unicode-spawn-args. > Now it's in master, and it breaks lots of test cases for me: > > t0050-filesystem > t0110-urlmatch-normalization > t4014-format-patch > t4041-diff-submodule-option > t4120-apply-po

Re: [PATCH 2/2] dir: remove PATH_MAX limitation

Am 09.07.2014 18:33, schrieb Junio C Hamano: > Karsten Blees writes: > >> 'git status' segfaults if a directory is longer than PATH_MAX, because >> processing .gitignore files in prep_exclude() writes past the end of a >> PATH_MAX-bounded buffer. >>

Re: [PATCH 1/2] symlinks: remove PATH_MAX limitation

Am 07.07.2014 20:30, schrieb Junio C Hamano: > Karsten Blees writes: > > The above cache_def_free(cache) does not free the cache itself, but > only its associated data, so the name cache_def_free() is somewhat > misleading. > You already merged this to master ("k

Re: [PATCH v1 3/4] hashmap: add simplified hashmap_get_from_hash() API

Am 07.07.2014 19:43, schrieb Junio C Hamano: > Karsten Blees writes: > >> Hashmap entries are typically looked up by just a key. The hashmap_get() >> API expects an initialized entry structure instead, to support compound >> keys. This flexibility is currently only neede

Re: [PATCH 2/2] dir: remove PATH_MAX limitation

Am 05.07.2014 12:48, schrieb Duy Nguyen: > On Sat, Jul 5, 2014 at 5:42 AM, Karsten Blees wrote: >> 'git status' segfaults if a directory is longer than PATH_MAX, because >> processing .gitignore files in prep_exclude() writes past the end of a >> PATH_MAX-b

[PATCH 2/2] dir: remove PATH_MAX limitation

tor, len is always 0. prep_exclude() can probably be simplified using more strbuf APIs. Signed-off-by: Karsten Blees --- dir.c | 35 +++ dir.h | 4 ++-- 2 files changed, 21 insertions(+), 18 deletions(-) diff --git a/dir.c b/dir.c index e65888d..8d4d83c 100644 ---

[PATCH 1/2] symlinks: remove PATH_MAX limitation

'git checkout' fails if a directory is longer than PATH_MAX, because the lstat_cache in symlinks.c checks if the leading directory exists using PATH_MAX-bounded string operations. Remove the limitation by using strbuf instead. Signed-off-by: Karsten Blees --- This fixes a bug on Wi

[PATCH v1 3/4] hashmap: add simplified hashmap_get_from_hash() API

hashmap lookups by just specifying the key and its hash code, i.e.: return hashmap_get_from_hash(map, hash(key), key); Signed-off-by: Karsten Blees --- Documentation/technical/api-hashmap.txt | 14 ++ builtin/describe.c | 4 +--- diffcore-

[PATCH v1 4/4] hashmap: add string interning API

etenv(), in case we ever encounter a platform where a call to getenv() invalidates previous getenv() results (which is allowed by POSIX). Signed-off-by: Karsten Blees --- Documentation/technical/api-hashmap.txt | 15 + hashmap.c

[PATCH v1 2/4] hashmap: improve struct hashmap member documentation

Signed-off-by: Karsten Blees --- Documentation/technical/api-hashmap.txt | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/Documentation/technical/api-hashmap.txt b/Documentation/technical/api-hashmap.txt index 4689968..dc21a7c 100644 --- a/Documentation

[PATCH v1 1/4] hashmap: factor out getting an int hash code from a, SHA1

Copying the first bytes of a SHA1 is duplicated in six places, however, the implications (wrong byte order on little-endian systems) is documented only once. Add a properly documented API for this. Signed-off-by: Karsten Blees --- Documentation/technical/api-hashmap.txt | 9 + builtin

[PATCH v1 0/4] hashmap improvements

Here are a few small hashmap improvements, partly resulting from recent discussion of the config-cache topic. Karsten Blees (4): hashmap: factor out getting an int hash code from a SHA1 hashmap: improve struct hashmap member documentation hashmap: add simplified hashmap_get_from_hash() API

Re: [PATCH v7 11/16] trace: add 'file:line' to all trace output

Am 02.07.2014 20:57, schrieb Junio C Hamano: > Karsten Blees writes: > >> +#else >> + >> +/* >> + * Macros to add file:line - see above for C-style declarations of how these >> + * should be used. >> + * >> + * TRACE_CONTEXT may be set

[PATCH v7 16/16] progress: simplify performance measurement by using getnanotime()

-by: Karsten Blees --- progress.c | 71 +++--- 1 file changed, 36 insertions(+), 35 deletions(-) diff --git a/progress.c b/progress.c index 261314e..412e6b1 100644 --- a/progress.c +++ b/progress.c @@ -12,13 +12,14 @@ #include "gett

[PATCH v7 15/16] wt-status: simplify performance measurement by using getnanotime()

Calculating duration from a single uint64_t is simpler than from a struct timeval. Change performance measurement for 'advice.statusuoption' from gettimeofday() to getnanotime(). Also initialize t_begin to prevent uninitialized variable warning. Signed-off-by: Karsten Blees --- w

  1   2   3   4   >