1. 09 Sep, 2021 1 commit
  2. 09 Aug, 2021 1 commit
  3. 08 Aug, 2021 1 commit
  4. 28 Apr, 2021 1 commit
    • refs: ensure loose refs adhere to path validation · e5851c62
      On Windows, we need to enforce MAX_PATH for loose references and their
      reflogs.  Ensure that any path - including the lock file - would fit
      within the 260 character maximum.
      
      We do not honor core.longpaths for loose reference files or reflogs.
      core.longpaths only applies to paths in the working directory.
      Edward Thomson committed
  5. 20 Apr, 2021 1 commit
    • git_reference_create_matching: Treat all-zero OID as "must be absent" · 95b7a639
      This is pretty useful in avoiding races: I want to create a ref only if
      it doesn't already exist.  I can't check first because of TOCTOU -- by
      the time I finish the check, someone else might have already created
      the ref.  And I can't take a lock because then I can't do the create,
      since the create expects to take the lock.
      
      The semantics are inspired by git update-ref, which allows an all-zero old
      value to mean that the ref must not exist.
      David Turner committed
  6. 14 Apr, 2021 1 commit
  7. 17 Feb, 2021 1 commit
  8. 27 Nov, 2020 1 commit
  9. 12 Jul, 2020 2 commits
    • refdb: extract function to check whether to append HEAD to the reflog · 1f39593b
      The logic to determine whether a reflog entry should be for the HEAD
      reference is non-trivial. Currently, the only user of this is the
      filesystem-based refdb, but with the advent of the reftable refdb we're
      going to add a second user that's interested in having the same
      behaviour.
      
      Let's pull out a new function that checks whether a given reference
      should cause a entry to be written to the HEAD reflog as a preparatory
      step.
      Patrick Steinhardt committed
    • refdb: extract function to check whether a reflog should be written · e02478b1
      The logic to determine whether a reflog should be written is
      non-trivial. Currently, the only user of this is the filesystem-based
      refdb, but with the advent of the reftable refdb we're going to add a
      second user that's interested in having the same behaviour.
      
      Let's pull out a new function that checks whether a given reference
      should cause a reflog to be written as a preparatory step.
      Patrick Steinhardt committed
  10. 01 Jun, 2020 1 commit
  11. 25 Mar, 2020 1 commit
  12. 22 Mar, 2020 1 commit
  13. 13 Dec, 2019 1 commit
    • refs: rename git_reference__set_name to git_reference__realloc · 97b8491b
      As git_reference__name will reallocate storage to account for longer
      names (it's actually allocator-dependent), it will cause all existing
      pointers to the old object to become dangling, as they now point to
      freed memory.
      
      Fix the issue by renaming to a more descriptive name, and pass a pointer
      to the actual reference that can safely be invalidated if the realloc
      succeeds.
      Etienne Samson committed
  14. 18 Oct, 2019 3 commits
    • refdb_fs: properly parse corrupted reflogs · 7968e90f
      In previous versions, libgit2 could be coerced into writing reflog
      messages with embedded newlines into the reflog by using
      `git_stash_save` with a message containing newlines. While the root
      cause is fixed now, it was noticed that upstream git is in fact able to
      read such corrupted reflog messages just fine.
      
      Make the reflog parser more lenient in order to just skip over
      malformatted reflog lines to bring us in line with git. This requires us
      to change an existing test that verified that we do indeed _fail_ to
      parse such logs.
      Patrick Steinhardt committed
    • refdb_fs: convert reflog parsing to use parser · 8532ed11
      The refdb_fs code to parse the reflog currently uses a hand-rolled
      parser. Convert it to use our `git_parse_ctx` structure instead.
      Patrick Steinhardt committed
    • reflog: allow adding entries with newlines in their message · d8233feb
      Currently, the reflog disallows any entries that have a message with
      newlines, as that would effectively break the reflog format, which may
      contain a single line per entry, only. Upstream git behaves a bit
      differently, though, especially when considering stashes: instead of
      rejecting any reflog entry with newlines, git will simply replace
      newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will
      create a reflog entry with "foo bar" as entry message.
      
      This commit adjusts our own logic to stop rejecting commit messages with
      newlines. Previously, this logic was part of `git_reflog_append`, only.
      There is a second place though where we add reflog entries, which is the
      serialization code in the filesystem refdb. As it didn't contain any
      sanity checks whatsoever, the refdb would have been perfectly happy to
      write malformatted reflog entries to the disk. This is being fixed with
      the same logic as for the reflog itself.
      Patrick Steinhardt committed
  15. 10 Oct, 2019 1 commit
    • refs: fix locks getting forcibly removed · 3335a034
      The flag GIT_FILEBUF_FORCE currently does two things:
           1. It will cause the filebuf to create non-existing leading
              directories for the file that is about to be written.
           2. It will forcibly remove any pre-existing locks.
      While most call sites actually do want (1), they do not want to
      remove pre-existing locks, as that renders the locking mechanisms
      effectively useless.
      Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to
      separate both behaviours cleanly from each other and convert
      callers to use it instead of `GIT_FILEBUF_FORCE` to have them
      honor locked files correctly.
      
      As this conversion removes all current users of `GIT_FILEBUF_FORCE`,
      this commit removes the flag altogether.
      Sebastian Henke committed
  16. 05 Sep, 2019 6 commits
  17. 20 Jul, 2019 1 commit
  18. 18 Jul, 2019 1 commit
  19. 15 Jun, 2019 2 commits
    • global: convert trivial `fnmatch` users to use `wildcard` · de70bb46
      Upstream git.git has converted its codebase to use wildcard in
      favor of fnmatch in commit 70a8fc999d (stop using fnmatch (either
      native or compat), 2014-02-15). To keep our own regex-matching in
      line with what git does, convert all trivial instances of
      `fnmatch` usage to use `wildcard`, instead. Trivial usage is
      defined to be use of `fnmatch` with either no flags or flags that
      have a 1:1 equivalent in wildmatch (PATHNAME, IGNORECASE).
      Patrick Steinhardt committed
    • posix: remove implicit include of "fnmatch.h" · 451df793
      We're about to phase out our bundled fnmatch implementation as
      git.git has moved to wildmatch long ago in 2014. To make it
      easier to spot which files are stilll using fnmatch, remove the
      implicit "fnmatch.h" include in "posix.h" and instead include it
      explicitly.
      Patrick Steinhardt committed
  20. 16 Apr, 2019 1 commit
  21. 15 Feb, 2019 5 commits
    • refdb_fs: fix race when migrating loose to packed refs in iteration · 94743daf
      Right now, we first load the packed refs cache and only afterwards load the
      loose references. This is susceptible to a race when the loose ref is being
      migrated to a packed cache by e.g. git-pack-refs(1):
      
                      libgit2                             git-pack-refs
      
         1. We load the packed ref, which
            does not yet have the migrated
            reference.
      
                                            2. git-pack-refs updates the packed ref
                                               file to have the migrated ref.
      
                                            3. git-pack-refs deletes the old loose
                                               ref.
      
         4. We look up the loose ref.
      
      So we now do not find the reference at all and will never iterate over it.
      
      Fix the issue by reversing the order: instead of first loading the packed refs,
      we will now look up the loose reference first. If it has already been deleted,
      then it must already be present in the packed-refs by definition, as git.git
      will only delete the reference after updating the packed refs file.
      Patrick Steinhardt committed
    • refdb_fs: remove ordering dependency on loose/packed refs loading · 3ff0e3b5
      Right now, loading loose refs has the side-effect of setting the
      `PACKREF_SHADOWED` flag for references that exist both in the loose and the
      packed refs. Because of this, we are force do first look up packed refs and only
      afterwards loading the packed refs. This is susceptible to a race, though, when
      refs are being repacked: when first loading the packed cache, then it may not
      yet have the migrated loose ref. But when now trying to look up the loose
      reference afterwards, then it may already have been migrated. Thus, we would
      fail to find this reference in this scenario.
      
      Remove this ordering dependency to allow fixing the above race. Instead of
      setting the flag when loading loose refs, we will now instead set it lazily when
      iterating over the loose refs. This even has the added benefit of not requiring
      us to lock the packed refs cache, as we already have an owned copy of it.
      Patrick Steinhardt committed
    • refdb_fs: do not lazily copy packed ref cache · 83333814
      When creating a new iterator, we eagerly load loose refs but only lazily create
      a copy of packed refs. The lazy load only happens as soon as we have iterated
      over all loose refs, opening up a potentially wide window for races. This
      may lead to an inconsistent view e.g. when the caller decides to reload packed
      references somewhen between iterating the loose refs, which is unexpected.
      
      Fix the issue by eagerly copying the sorted cache. Note that right now, we are
      heavily dependent on ordering here: we first need to reload packed refs, then we
      have to load loose refs and only as a last step are we allowed to copy the
      cache. This is because loading loose refs has the side-effect of setting the
      `PACKED_SHADOWED` flag in the packed refs cache, which we require to avoid
      outputting packed refs that already exist as loose refs.
      Patrick Steinhardt committed
    • refdb_fs: refactor error handling in iterator creation · 32063d82
      Refactor the error handling in `refdb_fs_backend__iterator` to always return the
      correct error code returned by the failing function.
      Patrick Steinhardt committed
    • refdb_fs: fix potential race with ref repacking in `exists` callback · 8c773438
      When repacking references, git.git will first update the packed refs and only
      afterwards delete any existing loose references that have now been moved to the
      new packed refs file. Due to this, there is a potential for racing if one first
      reads the packfile (which has not been updated yet) and only then trying to read
      the loose reference (which has just been deleted). In this case, one will
      incorrectly fail to lookup the reference and it will be reported as missing.
      Naturally, this is exactly what we've been doing in `refdb_fs_backend__exists`.
      
      Fix the race by reversing the lookup: we will now first check if the loose
      reference exists and only afterwards refresh the packed file.
      Patrick Steinhardt committed
  22. 22 Jan, 2019 1 commit
  23. 17 Jan, 2019 1 commit
  24. 19 Dec, 2018 1 commit
    • refdb_fs: refactor error handling in `refdb_reflog_fs__delete` · 8dde7e11
      The function `refdb_reflog_fs__delete` uses the `if (!error && foobar())`
      pattern of checking, where error conditions are being checked by following calls
      to different code. This does not match our current style, where the call-site of
      a function is usually directly responsible for checking the return value.
      
      Convert the function to use `if ((error = foobar()) < 0) goto out;` style. Note
      that this changes the code flow a bit: previously, we were always trying to
      delete empty reference hierarchies even if deleting the reflog entry has failed.
      This wasn't much of a problem -- if deletion failed, the hierarchy will still
      contain at least one file and thus the function call was an expensive no-op.
      Now, we will only perform this deletion if we have successfully removed the
      reflog.
      Patrick Steinhardt committed
  25. 01 Dec, 2018 1 commit
  26. 18 Nov, 2018 1 commit
  27. 13 Oct, 2018 1 commit