1. 06 Mar, 2019 1 commit
    • Jeff King's avatar
      compat/bswap: add include header guards · 33aa579a
      Jeff King authored
      Our compat/bswap.h lacks the usual preprocessor guards against multiple
      inclusion. This usually isn't an issue since it only gets included from
      git-compat-util.h, which has its own guards. But it would produce
      redeclaration errors if any file included it separately.
      
      Our hdr-check target would complain about this, except that it currently
      skips items in compat/ entirely.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      33aa579a
  2. 22 Feb, 2019 2 commits
    • Jeff Hostetler's avatar
      trace2: collect Windows-specific process information · 353d3d77
      Jeff Hostetler authored
      Add platform-specific interface to log information about the current
      process.
      
      On Windows, this interface is used to indicate whether the git process
      is running under a debugger and list names of the process ancestors.
      
      Information for other platforms is left for a future effort.
      Signed-off-by: default avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      353d3d77
    • Jeff Hostetler's avatar
      trace2: create new combined trace facility · ee4512ed
      Jeff Hostetler authored
      Create a new unified tracing facility for git.  The eventual intent is to
      replace the current trace_printf* and trace_performance* routines with a
      unified set of git_trace2* routines.
      
      In addition to the usual printf-style API, trace2 provides higer-level
      event verbs with fixed-fields allowing structured data to be written.
      This makes post-processing and analysis easier for external tools.
      
      Trace2 defines 3 output targets.  These are set using the environment
      variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT".  These may be
      set to "1" or to an absolute pathname (just like the current GIT_TRACE).
      
      * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command
        summary data.
      
      * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE.
        It extends the output with columns for the command process, thread,
        repo, absolute and relative elapsed times.  It reports events for
        child process start/stop, thread start/stop, and per-thread function
        nesting.
      
      * GIT_TR2_EVENT is a new structured format. It writes event data as a
        series of JSON records.
      
      Calls to trace2 functions log to any of the 3 output targets enabled
      without the need to call different trace_printf* or trace_performance*
      routines.
      Signed-off-by: default avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ee4512ed
  3. 15 Feb, 2019 1 commit
    • Johannes Schindelin's avatar
      mingw: safe-guard a bit more against getenv() problems · ca1b4116
      Johannes Schindelin authored
      Running up to v2.21.0, we fixed two bugs that were made prominent by the
      Windows-specific change to retain copies of only the 30 latest getenv()
      calls' returned strings, invalidating any copies of previous getenv()
      calls' return values.
      
      While this really shines a light onto bugs of the form where we hold
      onto getenv()'s return values without copying them, it is also a real
      problem for users.
      
      And even if Jeff King's patches merged via 773e4088 (Merge branch
      'jk/save-getenv-result', 2019-01-29) provide further work on that front,
      we are far from done. Just one example: on Windows, we unset environment
      variables when spawning new processes, which potentially invalidates
      strings that were previously obtained via getenv(), and therefore we
      have to duplicate environment values that are somehow involved in
      spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()).
      
      We do not have a chance to investigate, let address, all of those issues
      in time for v2.21.0, so let's at least help Windows users by increasing
      the number of getenv() calls' return values that are kept valid. The
      number 64 was determined by looking at the average number of getenv()
      calls per process in the entire test suite run on Windows (which is
      around 40) and then adding a bit for good measure. And it is a power of
      two (which would have hit yesterday's theme perfectly).
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ca1b4116
  4. 13 Feb, 2019 1 commit
    • Johannes Schindelin's avatar
      mingw: use a more canonical method to fix the CPU reporting · bb02e7a5
      Johannes Schindelin authored
      In `git version --build-options`, we report also the CPU, but in Git for
      Windows we actually cross-compile the 32-bit version in a 64-bit Git for
      Windows, so we cannot rely on the auto-detected value.
      
      In 3815f64b (mingw: fix CPU reporting in `git version
      --build-options`, 2019-02-07), we fixed this by a Windows-only
      workaround, making use of magic pre-processor constants, which works in
      GCC, but most likely not all C compilers.
      
      As pointed out by Eric Sunshine, there is a better way, anyway: to set
      the Makefile variable HOST_CPU explicitly for cross-compiled Git. So
      let's do that!
      
      This reverts commit 3815f64b partially.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      bb02e7a5
  5. 12 Feb, 2019 1 commit
  6. 07 Feb, 2019 1 commit
  7. 31 Jan, 2019 1 commit
    • Torsten Bögershausen's avatar
      Support working-tree-encoding "UTF-16LE-BOM" · aab2a1ae
      Torsten Bögershausen authored
      Users who want UTF-16 files in the working tree set the .gitattributes
      like this:
      test.txt working-tree-encoding=UTF-16
      
      The unicode standard itself defines 3 allowed ways how to encode UTF-16.
      The following 3 versions convert all back to 'g' 'i' 't' in UTF-8:
      
      a) UTF-16, without BOM, big endian:
      $ printf "\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c
      0000000    g   i   t
      
      b) UTF-16, with BOM, little endian:
      $ printf "\377\376g\000i\000t\000" | iconv -f UTF-16 -t UTF-8 | od -c
      0000000    g   i   t
      
      c) UTF-16, with BOM, big endian:
      $ printf "\376\377\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c
      0000000    g   i   t
      
      Git uses libiconv to convert from UTF-8 in the index into ITF-16 in the
      working tree.
      After a checkout, the resulting file has a BOM and is encoded in "UTF-16",
      in the version (c) above.
      This is what iconv generates, more details follow below.
      
      iconv (and libiconv) can generate UTF-16, UTF-16LE or UTF-16BE:
      
      d) UTF-16
      $ printf 'git' | iconv -f UTF-8 -t UTF-16 | od -c
      0000000  376 377  \0   g  \0   i  \0   t
      
      e) UTF-16LE
      $ printf 'git' | iconv -f UTF-8 -t UTF-16LE | od -c
      0000000    g  \0   i  \0   t  \0
      
      f)  UTF-16BE
      $ printf 'git' | iconv -f UTF-8 -t UTF-16BE | od -c
      0000000   \0   g  \0   i  \0   t
      
      There is no way to generate version (b) from above in a Git working tree,
      but that is what some applications need.
      (All fully unicode aware applications should be able to read all 3 variants,
      but in practise we are not there yet).
      
      When producing UTF-16 as an output, iconv generates the big endian version
      with a BOM. (big endian is probably chosen for historical reasons).
      
      iconv can produce UTF-16 files with little endianess by using "UTF-16LE"
      as encoding, and that file does not have a BOM.
      
      Not all users (especially under Windows) are happy with this.
      Some tools are not fully unicode aware and can only handle version (b).
      
      Today there is no way to produce version (b) with iconv (or libiconv).
      Looking into the history of iconv, it seems as if version (c) will
      be used in all future iconv versions (for compatibility reasons).
      
      Solve this dilemma and introduce a Git-specific "UTF-16LE-BOM".
      libiconv can not handle the encoding, so Git pick it up, handles the BOM
      and uses libiconv to convert the rest of the stream.
      (UTF-16BE-BOM is added for consistency)
      Rported-by: Adrián's avatarAdrián Gimeno Balaguer <adrigibal@gmail.com>
      Signed-off-by: default avatarTorsten Bögershausen <tboegi@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      aab2a1ae
  8. 29 Jan, 2019 1 commit
  9. 18 Jan, 2019 1 commit
    • Johannes Schindelin's avatar
      mingw: special-case arguments to `sh` · 9e9da23c
      Johannes Schindelin authored
      The MSYS2 runtime does its best to emulate the command-line wildcard
      expansion and de-quoting which would be performed by the calling Unix
      shell on Unix systems.
      
      Those Unix shell quoting rules differ from the quoting rules applying to
      Windows' cmd and Powershell, making it a little awkward to quote
      command-line parameters properly when spawning other processes.
      
      In particular, git.exe passes arguments to subprocesses that are *not*
      intended to be interpreted as wildcards, and if they contain
      backslashes, those are not to be interpreted as escape characters, e.g.
      when passing Windows paths.
      
      Note: this is only a problem when calling MSYS2 executables, not when
      calling MINGW executables such as git.exe. However, we do call MSYS2
      executables frequently, most notably when setting the use_shell flag in
      the child_process structure.
      
      There is no elegant way to determine whether the .exe file to be
      executed is an MSYS2 program or a MINGW one. But since the use case of
      passing a command line through the shell is so prevalent, we need to
      work around this issue at least when executing sh.exe.
      
      Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and
      whether it refers to the MSYS2 Bash, to determine whether we need to
      quote the arguments differently than usual.
      
      That still does not fix the issue completely, but at least it is
      something.
      
      Incidentally, this also fixes the problem where `git clone \\server\repo`
      failed due to incorrect handling of the backslashes when handing the path
      to the git-upload-pack process.
      
      Further, we need to take care to quote not only whitespace and
      backslashes, but also curly brackets. As aliases frequently go through
      the MSYS2 Bash, and as aliases frequently get parameters such as
      HEAD@{yesterday}, this is really important. As an early version of this
      patch broke this, let's make sure that this does not regress by adding a
      test case for that.
      Helped-by: default avatarKim Gybels <kgybels@infogroep.be>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9e9da23c
  10. 17 Jan, 2019 1 commit
    • Gábor Szeder's avatar
      compat/obstack: fix -Wcast-function-type warnings · 764473d2
      Gábor Szeder authored
      GCC 8 introduced the new -Wcast-function-type warning, which is
      implied by -Wextra (which, in turn is enabled in our DEVELOPER flags).
      When building Git with GCC 8 and this warning enabled on a non-glibc
      platform [1], one is greeted with a screenful of compiler
      warnings/errors:
      
        compat/obstack.c: In function '_obstack_begin':
        compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type]
           h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;
                         ^
        compat/obstack.c:163:16: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(void *, struct _obstack_chunk *)' [-Werror=cast-function-type]
           h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;
                        ^
        compat/obstack.c:116:8: error: cast between incompatible function types from 'struct _obstack_chunk * (*)(void *, long int)' to 'struct _obstack_chunk * (*)(long int)' [-Werror=cast-function-type]
            : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))
                ^
        compat/obstack.c:168:22: note: in expansion of macro 'CALL_CHUNKFUN'
           chunk = h->chunk = CALL_CHUNKFUN (h, h -> chunk_size);
                              ^~~~~~~~~~~~~
        <snip>
      
      'struct obstack' stores pointers to two functions to allocate and free
      "chunks", and depending on how obstack is used, these functions take
      either one parameter (like standard malloc() and free() do; this is
      how we use it in 'kwset.c') or two parameters.  Presumably to reduce
      memory footprint, a single field is used to store the function pointer
      for both signatures, and then it's casted to the appropriate signature
      when the function pointer is accessed.  These casts between function
      pointers with different number of parameters are what trigger those
      compiler errors.
      
      Modify 'struct obstack' to use unions to store function pointers with
      different signatures, and then use the union member with the
      appropriate signature when accessing these function pointers.  This
      eliminates the need for those casts, and thus avoids this compiler
      error.
      
      [1] Compiling 'compat/obstack.c' on a platform with glibc is sort of
          a noop, see the comment before '#  define ELIDE_CODE', so this is
          not an issue on common Linux distros.
      Signed-off-by: Gábor Szeder's avatarSZEDER Gábor <szeder.dev@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      764473d2
  11. 03 Jan, 2019 1 commit
  12. 26 Dec, 2018 1 commit
    • Torsten Bögershausen's avatar
      git clone <url> C:\cygwin\home\USER\repo' is working (again) · 1cadad6f
      Torsten Bögershausen authored
      A regression for cygwin users was introduced with commit 05b458c1,
       "real_path: resolve symlinks by hand".
      
      In the the commit message we read:
        The current implementation of real_path uses chdir() in order to resolve
          symlinks.  Unfortunately this isn't thread-safe as chdir() affects a
            process as a whole...
      
      The old (and non-thread-save) OS calls chdir()/pwd() had been
      replaced by a string operation.
      The cygwin layer "knows" that "C:\cygwin" is an absolute path,
      but the new string operation does not.
      
      "git clone <url> C:\cygwin\home\USER\repo" fails like this:
      fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo'
      
      The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
      is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
      in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
      
      Extract the needed code into compat/win32/path-utils.[ch] and use it
      for cygwin as well.
      Reported-by: Steven Penny's avatarSteven Penny <svnpenn@gmail.com>
      Helped-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarTorsten Bögershausen <tboegi@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1cadad6f
  13. 20 Nov, 2018 1 commit
  14. 16 Nov, 2018 1 commit
  15. 14 Nov, 2018 2 commits
  16. 05 Nov, 2018 1 commit
    • Steve Hoelzer's avatar
      poll: use GetTickCount64() to avoid wrap-around issues · e8dfcace
      Steve Hoelzer authored
      The value of timeout starts as an int value, and for this reason it
      cannot overflow unsigned long long aka ULONGLONG. The unsigned version
      of this initial value is available in orig_timeout. The difference
      (orig_timeout - elapsed) cannot wrap around because it is protected by
      a conditional (as can be seen in the patch text). Hence, the ULONGLONG
      difference can only have values that are smaller than the initial
      timeout value and truncation to int cannot overflow.
      Signed-off-by: default avatarSteve Hoelzer <shoelzer@gmail.com>
      [j6t: improved both implementation and log message]
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e8dfcace
  17. 31 Oct, 2018 5 commits
    • Johannes Schindelin's avatar
      mingw: fix isatty() after dup2() · ff8978d5
      Johannes Schindelin authored
      Since a9b8a09c (mingw: replace isatty() hack, 2016-12-22), we handle
      isatty() by special-casing the stdin/stdout/stderr file descriptors,
      caching the return value. However, we missed the case where dup2()
      overrides the respective file descriptor.
      
      That poses a problem e.g. where the `show` builtin asks for a pager very
      early, the `setup_pager()` function sets the pager depending on the
      return value of `isatty()` and then redirects stdout. Subsequently,
      `cmd_log_init_finish()` calls `setup_pager()` *again*. What should
      happen now is that `isatty()` reports that stdout is *not* a TTY and
      consequently stdout should be left alone.
      
      Let's override dup2() to handle this appropriately.
      
      This fixes https://github.com/git-for-windows/git/issues/1077Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ff8978d5
    • Johannes Schindelin's avatar
      mingw: unset PERL5LIB by default · 0e218f91
      Johannes Schindelin authored
      Git for Windows ships with its own Perl interpreter, and insists on
      using it, so it will most likely wreak havoc if PERL5LIB is set before
      launching Git.
      
      Let's just unset that environment variables when spawning processes.
      
      To make this feature extensible (and overrideable), there is a new
      config setting `core.unsetenvvars` that allows specifying a
      comma-separated list of names to unset before spawning processes.
      
      Reported by Gabriel Fuhrmann.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      0e218f91
    • Johannes Schindelin's avatar
    • Johannes Schindelin's avatar
      config: allow for platform-specific core.* config settings · 70fc5793
      Johannes Schindelin authored
      In the Git for Windows project, we have ample precendent for config
      settings that apply to Windows, and to Windows only.
      
      Let's formalize this concept by introducing a platform_core_config()
      function that can be #define'd in a platform-specific manner.
      
      This will allow us to contain platform-specific code better, as the
      corresponding variables no longer need to be exported so that they can
      be defined in environment.c and be set in config.c
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      70fc5793
    • Johannes Schindelin's avatar
      mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8) · fe21c6b2
      Johannes Schindelin authored
      On Windows, the authoritative environment is encoded in UTF-16. In Git
      for Windows, we convert that to UTF-8 (because UTF-16 is *such* a
      foreign idea to Git that its source code is unprepared for it).
      
      Previously, out of performance concerns, we converted the entire
      environment to UTF-8 in one fell swoop at the beginning, and upon
      putenv() and run_command() converted it back.
      
      Having a private copy of the environment comes with its own perils: when
      a library used by Git's source code tries to modify the environment, it
      does not really work (in Git for Windows' case, libcurl, see
      https://github.com/git-for-windows/git/compare/bcad1e6d58^...bcad1e6d58^2
      for a glimpse of the issues).
      
      Hence, it makes our environment handling substantially more robust if we
      switch to on-the-fly-conversion in `getenv()`/`putenv()` calls. Based
      on an initial version in the MSVC context by Jeff Hostetler, this patch
      makes it so.
      
      Surprisingly, this has a *positive* effect on speed: at the time when
      the current code was written, we tested the performance, and there were
      *so many* `getenv()` calls that it seemed better to convert everything
      in one go. In the meantime, though, Git has obviously been cleaned up a
      bit with regards to `getenv()` calls so that the Git processes spawned
      by the test suite use an average of only 40 `getenv()`/`putenv()` calls
      over the process lifetime.
      
      Speaking of the entire test suite: the total time spent in the
      re-encoding in the current code takes about 32.4 seconds (out of 113
      minutes runtime), whereas the code introduced in this patch takes only
      about 8.2 seconds in total. Not much, but it proves that we need not be
      concerned about the performance impact introduced by this patch.
      Helped-by: default avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      fe21c6b2
  18. 25 Oct, 2018 1 commit
  19. 24 Oct, 2018 6 commits
    • Anton Serbulov's avatar
      mingw: fix getcwd when the parent directory cannot be queried · 4745feeb
      Anton Serbulov authored
      `GetLongPathName()` function may fail when it is unable to query
      the parent directory of a path component to determine the long name
      for that component. It happens, because it uses `FindFirstFile()`
      function for each next short part of path. The `FindFirstFile()`
      requires `List Directory` and `Synchronize` desired access for a calling
      process.
      
      In case of lacking such permission for some part of path,
      the `GetLongPathName()` returns 0 as result and `GetLastError()`
      returns ERROR_ACCESS_DENIED.
      
      `GetFinalPathNameByHandle()` function can help in such cases, because
      it requires `Read Attributes` and `Synchronize` desired access to the
      target path only.
      
      The `GetFinalPathNameByHandle()` function was introduced on
      `Windows Server 2008/Windows Vista`. So we need to load it dynamically.
      
      `CreateFile()` parameters:
          `lpFileName` = path to the current directory
          `dwDesiredAccess` = 0 (it means `Read Attributes` and `Synchronize`)
          `dwShareMode` = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
                          (it prevents `Sharing Violation`)
          `lpSecurityAttributes` = NULL (default security attributes)
          `dwCreationDisposition` = OPEN_EXISTING
                                    (required to obtain a directory handle)
          `dwFlagsAndAttributes` = FILE_FLAG_BACKUP_SEMANTICS
                                   (required to obtain a directory handle)
          `hTemplateFile` = NULL (when opening an existing file or directory,
                                  `CreateFile` ignores this parameter)
      
      The string that is returned by `GetFinalPathNameByHandle()` function
      uses the \\?\ syntax. To skip the prefix and convert backslashes
      to slashes, the `normalize_ntpath()` mingw function will be used.
      
      Note: `GetFinalPathNameByHandle()` function returns a final path.
      It is the path that is returned when a path is fully resolved.
      For example, for a symbolic link named "C:\tmp\mydir" that points to
      "D:\yourdir", the final path would be "D:\yourdir".
      Signed-off-by: default avatarAnton Serbulov <aserbulov@plesk.com>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4745feeb
    • Johannes Schindelin's avatar
      mingw: ensure `getcwd()` reports the correct case · 937974fc
      Johannes Schindelin authored
      When switching the current working directory, say, in PowerShell, it is
      quite possible to use a different capitalization than the one that is
      recorded on disk. While doing the same in `cmd.exe` adjusts the
      capitalization magically, that does not happen in PowerShell so that
      `getcwd()` returns the current directory in a different way than is
      recorded on disk.
      
      Typically this creates no problems except when you call
      
      	git log .
      
      in a subdirectory called, say, "GIT/" but you switched to "Git/" and
      your `getcwd()` reports the latter, then Git won't understand that you
      wanted to see the history as per the `GIT/` subdirectory but it thinks you
      wanted to see the history of some directory that may have existed in the
      past (but actually never did).
      
      So let's be extra careful to adjust the capitalization of the current
      directory before working with it.
      
      Reported by a few PowerShell power users ;-)
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      937974fc
    • Johannes Schindelin's avatar
      mingw: load system libraries the recommended way · c6f050a4
      Johannes Schindelin authored
      When we access IPv6-related functions, we load the corresponding system
      library using the `LoadLibrary()` function, which is not the recommended
      way to load system libraries.
      
      In practice, it does not make a difference: the `ws2_32.dll` library
      containing the IPv6 functions is already loaded into memory, so
      LoadLibrary() simply reuses the already-loaded library.
      
      Still, recommended way is recommended way, so let's use that instead.
      
      While at it, also adjust the code in contrib/ that loads system libraries.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c6f050a4
    • Karsten Blees's avatar
      mingw: implement nanosecond-precision file times · d7e8c874
      Karsten Blees authored
      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 performance issues when using Git variants with
      different file time resolutions, as the timestamps are stored in the Git
      index: after updating the index with a Git variant that uses
      second-precision file times, a nanosecond-aware Git will think that
      pretty much every single file listed in the index is out of date.
      Signed-off-by: default avatarKarsten Blees <blees@dcon.de>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d7e8c874
    • Karsten Blees's avatar
      mingw: replace MSVCRT's fstat() with a Win32-based implementation · d75e6973
      Karsten Blees authored
      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
      compatible 'struct stat' with nanosecond-precision file times.
      
      This allows us also to implement some clever code to handle pipes and
      character devices in our own way.
      Signed-off-by: default avatarKarsten Blees <blees@dcon.de>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d75e6973
    • Johannes Schindelin's avatar
      mingw: factor out code to set stat() data · 7bf19838
      Johannes Schindelin authored
      In our fstat() emulation, we convert the file metadata from Win32 data
      structures to an emulated POSIX structure.
      
      To structure the code better, let's factor that part out into its own
      function.
      
      Note: it would be tempting to try to unify this code with the part of
      do_lstat() that does the same thing, but they operate on different data
      structures: BY_HANDLE_FILE_INFORMATION vs WIN32_FILE_ATTRIBUTE_DATA. So
      unfortunately, they cannot be unified.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      7bf19838
  20. 16 Oct, 2018 3 commits
  21. 04 Oct, 2018 1 commit
  22. 11 Sep, 2018 1 commit
  23. 15 Aug, 2018 1 commit
  24. 13 Aug, 2018 1 commit
    • Johannes Sixt's avatar
      mingw: enable atomic O_APPEND · d6410975
      Johannes Sixt authored
      The Windows CRT implements O_APPEND "manually": on write() calls, the
      file pointer is set to EOF before the data is written. Clearly, this is
      not atomic. And in fact, this is the root cause of failures observed in
      t5552-skipping-fetch-negotiator.sh and t5503-tagfollow.sh, where
      different processes write to the same trace file simultanously; it also
      occurred in t5400-send-pack.sh, but there it was worked around in
      71406ed4 ("t5400: avoid concurrent writes into a trace file",
      2017-05-18).
      
      Fortunately, Windows does support atomic O_APPEND semantics using the
      file access mode FILE_APPEND_DATA. Provide an implementation that does.
      
      This implementation is minimal in such a way that it only implements
      the open modes that are actually used in the Git code base. Emulation
      for other modes can be added as necessary later. To become aware of
      the necessity early, the unusal error ENOSYS is reported if an
      unsupported mode is encountered.
      Diagnosed-by: Johannes Schindelin's avatarJohannes Schindelin <Johannes.Schindelin@gmx.de>
      Helped-by: default avatarJeff Hostetler <git@jeffhostetler.com>
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d6410975
  25. 16 Jul, 2018 1 commit
  26. 11 Apr, 2018 1 commit
  27. 19 Mar, 2018 1 commit
    • Johannes Schindelin's avatar
      mingw: abort on invalid strftime formats · 9ee0540a
      Johannes Schindelin authored
      On Windows, strftime() does not silently ignore invalid formats, but
      warns about them and then returns 0 and sets errno to EINVAL.
      
      Unfortunately, Git does not expect such a behavior, as it disagrees
      with strftime()'s semantics on Linux. As a consequence, Git
      misinterprets the return value 0 as "I need more space" and grows the
      buffer. As the larger buffer does not fix the format, the buffer grows
      and grows and grows until we are out of memory and abort.
      
      Ideally, we would switch off the parameter validation just for
      strftime(), but we cannot even override the invalid parameter handler
      via _set_thread_local_invalid_parameter_handler() using MINGW because
      that function is not declared. Even _set_invalid_parameter_handler(),
      which *is* declared, does not help, as it simply does... nothing.
      
      So let's just bite the bullet and override strftime() for MINGW and
      abort on an invalid format string. While this does not provide the
      best user experience, it is the best we can do.
      
      See https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx for more
      details.
      
      This fixes https://github.com/git-for-windows/git/issues/863Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9ee0540a