1. 10 Mar, 2018 1 commit
    • 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
  2. 08 Jun, 2017 1 commit
    • settings: rename `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION` · 6c23704d
      Initially, the setting has been solely used to enable the use of
      `fsync()` when creating objects. Since then, the use has been extended
      to also cover references and index files. As the option is not yet part
      of any release, we can still correct this by renaming the option to
      something more sensible, indicating not only correlation to objects.
      
      This commit renames the option to `GIT_OPT_ENABLE_FSYNC_GITDIR`. We also
      move the variable from the object to repository source code.
      Patrick Steinhardt committed
  3. 05 May, 2017 1 commit
  4. 06 Mar, 2017 1 commit
  5. 02 Mar, 2017 1 commit
  6. 01 Mar, 2017 1 commit
  7. 28 Feb, 2017 6 commits
  8. 25 Feb, 2017 2 commits
  9. 13 Feb, 2017 2 commits
  10. 29 Dec, 2016 1 commit
  11. 04 Nov, 2016 1 commit
    • branch: fix forced branch creation on HEAD of a bare repo · f9793884
      The code correctly detects that forced creation of a branch on a
      nonbare repo should not be able to overwrite a branch which is
      the HEAD reference.  But there's no reason to prevent this on
      a bare repo, and in fact, git allows this.  I.e.,
      
         git branch -f master new_sha
      
      works on a bare repo with HEAD set to master.  This change fixes
      that problem, and updates tests so that, for this case, both the
      bare and nonbare cases are checked for correct behavior.
      John Fultz committed
  12. 22 Apr, 2016 1 commit
  13. 11 Apr, 2016 2 commits
  14. 03 Mar, 2016 1 commit
  15. 28 Feb, 2016 1 commit
  16. 12 Nov, 2015 2 commits
  17. 03 Nov, 2015 1 commit
  18. 29 Oct, 2015 1 commit
  19. 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
  20. 12 Jul, 2015 1 commit
  21. 26 Jun, 2015 1 commit
  22. 22 May, 2015 1 commit
    • branch: error out if we cannot find the remote · 5014fe95
      When we look for which remote corresponds to a remote-tracking branch,
      we look in the refspecs to see which ones matches. If none do, we should
      abort. We currently ignore the error message from this operation, so
      let's not do that anymore.
      
      As part of the test we're writing, let's test for the expected behaviour
      if we cannot find a refspec which tells us what the remote-tracking
      branch for a remote would look like.
      Carlos Martín Nieto committed
  23. 13 May, 2015 1 commit
    • remote: remove live changing of refspecs · 77254990
      The base refspecs changing can be a cause of confusion as to what is the
      current base refspec set and complicate saving the remote's
      configuration.
      
      Change `git_remote_add_{fetch,push}()` to update the configuration
      instead of an instance.
      
      This finally makes `git_remote_save()` a no-op, it will be removed in a
      later commit.
      Carlos Martín Nieto committed
  24. 16 Mar, 2015 1 commit
  25. 08 Mar, 2015 1 commit
  26. 04 Mar, 2015 2 commits
  27. 03 Mar, 2015 4 commits