1. 01 Jun, 2018 11 commits
  2. 10 Mar, 2018 24 commits
    • tree: initialize the id we use for testing submodule insertions · 9e98f49d
      Instead of laving it uninitialized and relying on luck for it to be non-zero,
      let's give it a dummy hash so we make valgrind happy (in this case the hash
      comes from `sha1sum </dev/null`.
      Carlos Martín Nieto committed
    • checkout test: further ensure workdir perms are updated · 1b853c48
      When both the index _and_ the working directory has changed
      permissions on a file permissions on a file - but only the permissions,
      such that the contents of the file are identical - ensure that
      `git_checkout` updates the permissions to match the checkout target.
      Edward Thomson committed
    • checkout test: ensure workdir perms are updated · 73615900
      When the working directory has changed permissions on a file - but only
      the permissions, such that the contents of the file are identical -
      ensure that `git_checkout` updates the permissions to match the checkout
      target.
      Edward Thomson committed
    • diff_tform: fix rename detection with rewrite/delete pair · e74e05ed
      A rewritten file can either be classified as a modification of its
      contents or of a delete of the complete file followed by an addition of
      the new content. This distinction becomes important when we want to
      detect renames for rewrites. Given a scenario where a file "a" has been
      deleted and another file "b" has been renamed to "a", this should be
      detected as a deletion of "a" followed by a rename of "a" -> "b". Thus,
      splitting of the original rewrite into a delete/add pair is important
      here.
      
      This splitting is represented by a flag we can set at the current delta.
      While the flag is already being set in case we want to break rewrites,
      we do not do so in case where the `GIT_DIFF_FIND_RENAMES_FROM_REWRITES`
      flag is set. This can trigger an assert when we try to match the source
      and target deltas.
      
      Fix the issue by setting the `GIT_DIFF_FLAG__TO_SPLIT` flag at the delta
      when it is a rename target and `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` is
      set.
      Patrick Steinhardt committed
    • tests: add rename-rewrite scenarios to "renames" repository · e229e90d
      Add two more scenarios to the "renames" repository. The first scenario
      has a major rewrite of a file and a delete of another file, the second
      scenario has a deletion of a file and rename of another file to the
      deleted file. Both scenarios will be used in the following commit.
      Patrick Steinhardt committed
    • tests: diff::rename: use defines for commit OIDs · be205dfa
      While we frequently reuse commit OIDs throughout the file, we do not
      have any constants to refer to these commits. Make this a bit easier to
      read by giving the commit OIDs somewhat descriptive names of what kind
      of commit they refer to.
      Patrick Steinhardt committed
    • merge: virtual commit should be last argument to merge-base · b3c0d43c
      Our virtual commit must be the last argument to merge-base: since our
      algorithm pushes _both_ parents of the virtual commit, it needs to be
      the last argument, since merge-base:
      
      > Given three commits A, B and C, git merge-base A B C will compute the
      > merge base between A and a hypothetical commit M
      
      We want to calculate the merge base between the actual commit ("two")
      and the virtual commit ("one") - since one actually pushes its parents
      to the merge-base calculation, we need to calculate the merge base of
      "two" and the parents of one.
      Tyrie Vella committed
    • merge::trees::recursive: test for virtual base building · dc51d774
      Virtual base building: ensure that the virtual base is created and
      revwalked in the same way as git.
      Edward Thomson committed
    • merge: reverse merge bases for recursive merge · b2b37077
      When the commits being merged have multiple merge bases, reverse the
      order when creating the virtual merge base.  This is for compatibility
      with git's merge-recursive algorithm, and ensures that we build
      identical trees.
      
      Git does this to try to use older merge bases first.  Per 8918b0c:
      
      > It seems to be the only sane way to do it: when a two-head merge is
      > done, and the merge-base and one of the two branches agree, the
      > merge assumes that the other branch has something new.
      >
      > If we start creating virtual commits from newer merge-bases, and go
      > back to older merge-bases, and then merge with newer commits again,
      > chances are that a patch is lost, _because_ the merge-base and the
      > head agree on it. Unlikely, yes, but it happened to me.
      Edward Thomson committed
    • Fix unpack double free · e83efde4
      If an element has been cached, but then the call to
      packfile_unpack_compressed() fails, the very next thing that happens is
      that its data is freed and then the element is not removed from the
      cache, which frees the data again.
      
      This change sets obj->data to NULL to avoid the double-free. It also
      stops trying to resolve deltas after two continuous failed rounds of
      resolution, and adds a test for this.
      lhchavez committed
    • diff_file: properly refcount blobs when initializing file contents · a521f5b1
      When initializing a `git_diff_file_content` from a source whose data is
      derived from a blob, we simply assign the blob's pointer to the
      resulting struct without incrementing its refcount. Thus, the structure
      can only be used as long as the blob is kept alive by the caller.
      
      Fix the issue by using `git_blob_dup` instead of a direct assignment.
      This function will increment the refcount of the blob without allocating
      new memory, so it does exactly what we want. As
      `git_diff_file_content__unload` already frees the blob when
      `GIT_DIFF_FLAG__FREE_BLOB` is set, we don't need to add new code
      handling the free but only have to set that flag correctly.
      Patrick Steinhardt committed
    • libFuzzer: Fix missing trailer crash · a3cd5e94
      This change fixes an invalid memory access when the trailer is missing /
      corrupt.
      
      Found using libFuzzer.
      lhchavez committed
    • libFuzzer: Fix a git_packfile_stream leak · 5cc3971a
      This change ensures that the git_packfile_stream object in
      git_indexer_append() does not leak when the stream has errors.
      
      Found using libFuzzer.
      lhchavez committed
    • checkout: test force checkout when mode changes · e66bc08c
      Test that we can successfully force checkout a target when the file
      contents are identical, but the mode has changed.
      Edward Thomson committed
    • refs: do not use peeled OID if peeling to a tag · cda18f9b
      If a reference stored in a packed-refs file does not directly point to a
      commit, tree or blob, the packed-refs file will also will include a
      fully-peeled OID pointing to the first underlying object of that type.
      If we try to peel a reference to an object, we will use that peeled OID
      to speed up resolving the object.
      
      As a reference for an annotated tag does not directly point to a commit,
      tree or blob but instead to the tag object, the packed-refs file will
      have an accomodating fully-peeled OID pointing to the object referenced
      by that tag. When we use the fully-peeled OID pointing to the referenced
      object when peeling, we obviously cannot peel that to the tag anymore.
      
      Fix this issue by not using the fully-peeled OID whenever we want to
      peel to a tag. Note that this does not include the case where we want to
      resolve to _any_ object type. Existing code may make use from the fact
      that we resolve those to commit objects instead of tag objects, even
      though that behaviour is inconsistent between packed and loose
      references. Furthermore, some tests of ours make the assumption that we
      in fact resolve those references to a commit.
      Patrick Steinhardt committed
    • ignore: honor case insensitivity for negative ignores · 4296a36b
      When computing negative ignores, we throw away any rule which does not
      undo a previous rule to optimize. But on case insensitive file systems,
      we need to keep in mind that a negative ignore can also undo a previous
      rule with different case, which we did not yet honor while determining
      whether a rule undoes a previous one. So in the following example, we
      fail to unignore the "/Case" directory:
      
          /case
          !/Case
      
      Make both paths checking whether a plain- or wildcard-based rule undo a
      previous rule aware of case-insensitivity. This fixes the described
      issue.
      Patrick Steinhardt committed
    • tests: status: additional test for negative ignores with pattern · 32cc5edc
      This test is by Carlos Martín Nieto.
      Patrick Steinhardt committed
    • ignore: keep negative rules containing wildcards · 5c15cd94
      Ignore rules allow for reverting a previously ignored rule by prefixing
      it with an exclamation mark. As such, a negative rule can only override
      previously ignored files. While computing all ignore patterns, we try to
      use this fact to optimize away some negative rules which do not override
      any previous patterns, as they won't change the outcome anyway.
      
      In some cases, though, this optimization causes us to get the actual
      ignores wrong for some files. This may happen whenever the pattern
      contains a wildcard, as we are unable to reason about whether a pattern
      overrides a previous pattern in a sane way. This happens for example in
      the case where a gitignore file contains "*.c" and "!src/*.c", where we
      wouldn't un-ignore files inside of the "src/" subdirectory.
      
      In this case, the first solution coming to mind may be to just strip the
      "src/" prefix and simply compare the basenames. While that would work
      here, it would stop working as soon as the basename pattern itself is
      different, like for example with "*x.c" and "!src/*.c. As such, we
      settle for the easier fix of just not optimizing away rules that contain
      a wildcard.
      Patrick Steinhardt committed
    • Remove invalid submodule · 54d4e5de
      Fixes #4274
      Etienne Samson committed
  3. 13 Jun, 2017 5 commits