1. 07 Oct, 2017 1 commit
    • checkout: do not test file mode on Windows · 128c5ca9
      On Windows, we do not support file mode changes, so do not test
      for type changes between the disk and tree being checked out.
      
      We could have false positives since the on-disk file can only have
      an (effective) mode of 0100644 since NTFS does not support executable
      files.  If the tree being checked out did have an executable file,
      we would erroneously decide that the file on disk had been changed.
      Edward Thomson committed
  2. 06 Oct, 2017 1 commit
    • checkout: treat files as modified if mode differs · 752b7c79
      When performing a forced checkout, treat files as modified when the
      workdir or the index is identical except for the mode.  This ensures
      that force checkout will update the mode to the target.  (Apply this
      check for regular files only, if one of the items was a file and the
      other was another type of item then this would be a typechange and
      handled independently.)
      Edward Thomson committed
  3. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  4. 10 Jun, 2017 1 commit
    • checkout: cope with untracked files in directory deletion · 83989d70
      When deleting a directory during checkout, do not simply delete the
      directory, since there may be untracked files.  Instead, go into
      the iterator and examine each file.
      
      In the original code (the code with the faulty assumption), we look to
      see if there's an index entry beneath the directory that we want to
      remove.   Eg, it looks to see if we have a workdir entry foo and an
      index entry foo/bar.txt. If this is not the case, then the working
      directory must have precious files in that directory. This part is okay.
      The part that's not okay is if there is an index entry foo/bar.txt. It
      just blows away the whole damned directory.
      
      That's not cool.
      
      Instead, by simply pushing the directory itself onto the stack and
      iterating each entry, we will deal with the files one by one - whether
      they're in the index (and can be force removed) or not (and are
      precious).
      
      The original code was a bad optimization, assuming that we didn't need
      to git_iterator_advance_into if there was any index entry in the folder.
      That's wrong - we could have optimized this iff all folder entries are
      in the index.
      
      Instead, we need to simply dig into the directory and analyze its
      entries.
      Edward Thomson committed
  5. 20 Mar, 2017 1 commit
    • checkout: fix double-free of checkout_data's mkdir_map · 77c8ee74
      We currently call `git_strmap_free` on `checkout_data.mkdir_map` in the
      `checkout_data_clear` function. The only thing protecting us from a
      double-free is that the `git_strmap_free` function is in fact not a
      function, but a macro that also sets the map to NULL.
      
      Remove the second call to `git_strmap_free` and explicitly set the map
      member to NULL.
      Patrick Steinhardt committed
  6. 17 Feb, 2017 1 commit
  7. 30 Dec, 2016 1 commit
    • Fix handling of GIT_CHECKOUT_DISABLE_PATHSPEC_MATCH flag. · 5f959dca
      git_checkout_tree() sets up its working directory iterator to respect the
      pathlist if GIT_CHECKOUT_DISABLE_PATHSPEC_MATCH is present, which is great.
      What's not so great is that this iterator is then used side-by-side with
      an iterator created by git_checkout_iterator(), which did not set up its
      pathlist appropriately (although the iterator mirrors all other iterator
      options).
      
      This could cause git_checkout_tree() to delete working tree files which
      were not specified in the pathlist when GIT_CHECKOUT_DISABLE_PATHSPEC_MATCH
      was used, as the unsynchronized iterators causes git_checkout_tree() to think
      that files have been deleted between the two trees.  Oops.
      
      And added a test which fails without this fix (specifically, the final check
      for "testrepo/README" to still be present fails).
      John Fultz committed
  8. 29 Dec, 2016 1 commit
  9. 14 Nov, 2016 1 commit
  10. 14 Sep, 2016 1 commit
    • checkout: don't try to calculate oid for directories · 955c99c2
      When trying to determine if we can safely overwrite an existing workdir
      item, we may need to calculate the oid for the workdir item to determine
      if its identical to the old side (and eligible for removal).
      
      We previously did this regardless of the type of entry in the workdir;
      if it was a directory, we would open(2) it and then try to read(2).
      The read(2) of a directory fails on many platforms, so we would treat it
      as if it were unmodified and continue to perform the checkout.
      
      On FreeBSD, you _can_ read(2) a directory, so this pattern failed.  We
      would calculate an oid from the data read and determine that the
      directory was modified and would therefore generate a checkout conflict.
      
      This reliance on read(2) is silly (and was most likely accidentally
      giving us the behavior we wanted), we should be explicit about the
      directory test.
      Edward Thomson committed
  11. 30 Aug, 2016 1 commit
    • git_checkout_tree options fix · 88cfe614
      According to the reference the git_checkout_tree and git_checkout_head
      functions should accept NULL in the opts field
      
      This was broken since the opts field was dereferenced and thus lead to a
      crash.
      Stefan Huber committed
  12. 15 Jun, 2016 1 commit
  13. 26 May, 2016 2 commits
  14. 02 May, 2016 1 commit
  15. 23 Mar, 2016 4 commits
    • iterator: drop `advance_into_or_over` · 0a2e1032
      Now that iterators do not return `GIT_ENOTFOUND` when advancing
      into an empty directory, we do not need a special `advance_into_or_over`
      function.
      Edward Thomson committed
    • iterator: combine fs+workdir iterators more completely · 0e0589fc
      Drop some of the layers of indirection between the workdir and the
      filesystem iterators.  This makes the code a little bit easier to
      follow, and reduces the number of unnecessary allocations a bit as
      well.  (Prior to this, when we filter entries, we would allocate them,
      filter them and then free them; now we do the filtering before
      allocation.)
      
      Also, rename `git_iterator_advance_over_with_status` to just
      `git_iterator_advance_over`.  Mostly because it's a fucking long-ass
      function name otherwise.
      Edward Thomson committed
    • checkout: provide internal func to compute target path · 702b23d7
      Many code paths in checkout need the final, full on-disk path of the
      file they're writing.  (No surprise).  However, they all munge the
      `data->path` buffer themselves to get there.  Provide a nice helper
      method for them.
      
      Plus, drop the use `git_iterator_current_workdir_path` which does the
      same thing but different.  Checkout is the only caller of this silly
      function, which lets us remove it.
      Edward Thomson committed
    • iterator: disambiguate reset and reset_range · 684b35c4
      Disambiguate the reset and reset_range functions.  Now reset_range
      with a NULL path will clear the start or end; reset will leave the
      existing start and end unchanged.
      Edward Thomson committed
  16. 17 Feb, 2016 1 commit
    • index: allow read of index w/ illegal entries · 318b825e
      Allow `git_index_read` to handle reading existing indexes with
      illegal entries.  Allow the low-level `git_index_add` to add
      properly formed `git_index_entry`s even if they contain paths
      that would be illegal for the current filesystem (eg, `AUX`).
      Continue to disallow `git_index_add_bypath` from adding entries
      that are illegal universally illegal (eg, `.git`, `foo/../bar`).
      Edward Thomson committed
  17. 11 Feb, 2016 1 commit
  18. 09 Feb, 2016 1 commit
  19. 23 Nov, 2015 1 commit
    • checkout: only consider nsecs when built that way · 25e84f95
      When examining the working directory and determining whether it's
      up-to-date, only consider the nanoseconds in the index entry when
      built with `GIT_USE_NSEC`.  This prevents us from believing that
      the working directory is always dirty when the index was originally
      written with a git client that uinderstands nsecs (like git 2.x).
      Edward Thomson committed
  20. 28 Oct, 2015 1 commit
  21. 05 Oct, 2015 1 commit
  22. 17 Sep, 2015 1 commit
    • git_futils_mkdir_*: make a relative-to-base mkdir · ac2fba0e
      Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter
      assumes that we own everything beneath the base, as if it were
      being called with a base of the repository or working directory,
      and is tailored towards checkout and ensuring that there is no
      bogosity beneath the base that must be cleaned up.
      
      This is (at best) slow and (at worst) unsafe in the larger context
      of a filesystem where we do not own things and cannot do things like
      unlink symlinks that are in our way.
      Edward Thomson committed
  23. 16 Sep, 2015 1 commit
    • checkout: overwrite files with differing modes · eea7c850
      When a file exists on disk and we're checking out a file that differs
      in executableness, remove the old file.  This allows us to recreate the
      new file with p_open, which will take the new mode into account and
      handle setting the umask properly.
      
      Remove any notion of chmod'ing existing files, since it is now handled
      by the aforementioned removal and was incorrect, as it did not take
      umask into account.
      Edward Thomson committed
  24. 30 Aug, 2015 1 commit
  25. 28 Aug, 2015 1 commit
  26. 12 Jul, 2015 1 commit
  27. 25 Jun, 2015 1 commit
  28. 22 Jun, 2015 3 commits
    • submodule: add an ignore option to status · c6f489c9
      This lets us specify in the status call which ignore rules we want to
      use (optionally falling back to whatever the submodule has in its
      configuration).
      
      This removes one of the reasons for having `_set_ignore()` set the value
      in-memory. We re-use the `IGNORE_RESET` value for this as it is no
      longer relevant but has a similar purpose to `IGNORE_FALLBACK`.
      
      Similarly, we remove `IGNORE_DEFAULT` which does not have use outside of
      initializers and move that to fall back to the configuration as well.
      Carlos Martín Nieto committed
    • submodule: don't let status change an existing instance · 64bbd47a
      As submodules are becomes more like values, we should not let a status
      check to update its properties. Instead of taking a submodule, have
      status take a repo and submodule name.
      Carlos Martín Nieto committed
    • submodule: remove the per-repo cache · dfda2f68
      Having this cache and giving them out goes against our multithreading
      guarantees and it makes it impossible to use submodules in a
      multi-threaded environment, as any thread can ask for a refresh which
      may reallocate some string in the submodule struct which we've accessed
      in a different one via a getter.
      
      This makes the submodules behave more like remotes, where each object is
      created upon request and not shared except explicitly by the user. This
      means that some tests won't pass yet, as they assume they can affect the
      submodule objects in the cache and that will affect later operations.
      Carlos Martín Nieto committed
  29. 20 Jun, 2015 1 commit
  30. 16 Jun, 2015 1 commit
  31. 29 May, 2015 1 commit
    • Rename GIT_EMERGECONFLICT to GIT_ECONFLICT · 885b94aa
      We do not error on "merge conflicts"; on the contrary, merge conflicts
      are a normal part of merging.  We only error on "checkout conflicts",
      where a change exists in the index or the working directory that would
      otherwise be overwritten by performing the checkout.
      
      This *may* happen during merge (after the production of the new index
      that we're going to checkout) but it could happen during any checkout.
      Edward Thomson committed
  32. 11 May, 2015 1 commit
  33. 04 May, 2015 2 commits