1. 17 Dec, 2018 1 commit
  2. 16 Dec, 2018 2 commits
  3. 15 Dec, 2018 1 commit
    • Nick Thomas's avatar
      Fix repository cleanup with object storage on · 0b74b863
      Nick Thomas authored
      When the BFG object map file is in object storage (i.e., uploads in
      general are placed into object storage), we get an instance of the
      Gitlab::HttpIO class. This doesn't behave as expected when you try to
      read past EOF, so we need to explicitly check for this condition to
      avoid ending up in a tight loop around io.read
  4. 14 Dec, 2018 2 commits
  5. 13 Dec, 2018 7 commits
  6. 11 Dec, 2018 2 commits
  7. 10 Dec, 2018 1 commit
  8. 09 Dec, 2018 1 commit
  9. 08 Dec, 2018 1 commit
  10. 07 Dec, 2018 8 commits
    • Travis Miller's avatar
    • Zeger-Jan van de Weg's avatar
      Allow public forks to be deduplicated · 896c0bdb
      Zeger-Jan van de Weg authored
      When a project is forked, the new repository used to be a deep copy of everything
      stored on disk by leveraging `git clone`. This works well, and makes isolation
      between repository easy. However, the clone is at the start 100% the same as the
      origin repository. And in the case of the objects in the object directory, this
      is almost always going to be a lot of duplication.
      Object Pools are a way to create a third repository that essentially only exists
      for its 'objects' subdirectory. This third repository's object directory will be
      set as alternate location for objects. This means that in the case an object is
      missing in the local repository, git will look in another location. This other
      location is the object pool repository.
      When Git performs garbage collection, it's smart enough to check the
      alternate location. When objects are duplicated, it will allow git to
      throw one copy away. This copy is on the local repository, where to pool
      remains as is.
      These pools have an origin location, which for now will always be a
      repository that itself is not a fork. When the root of a fork network is
      forked by a user, the fork still clones the full repository. Async, the
      pool repository will be created.
      Either one of these processes can be done earlier than the other. To
      handle this race condition, the Join ObjectPool operation is
      idempotent. Given its idempotent, we can schedule it twice, with the
      same effect.
      To accommodate the holding of state two migrations have been added.
      1. Added a state column to the pool_repositories column. This column is
      managed by the state machine, allowing for hooks on transitions.
      2. pool_repositories now has a source_project_id. This column in
      convenient to have for multiple reasons: it has a unique index allowing
      the database to handle race conditions when creating a new record. Also,
      it's nice to know who the host is. As that's a short link to the fork
      networks root.
      Object pools are only available for public project, which use hashed
      storage and when forking from the root of the fork network. (That is,
      the project being forked from itself isn't a fork)
      In this commit message I use both ObjectPool and Pool repositories,
      which are alike, but different from each other. ObjectPool refers to
      whatever is on the disk stored and managed by Gitaly. PoolRepository is
      the record in the database.
    • Felipe Artur's avatar
    • Mark Chao's avatar
      Fix commit with two parents is set with wrong direct_ancestor · c6c53d1c
      Mark Chao authored
      If a commit has two parents, one is direct ancestor, and one is not,
      and the order of `commits` is in such fashion that the non-ancestor
      side is visited first, the commit would be determined as non-ancestor,
      when in fact it can be.
      Therefore we should first determine all direct ancestors
      prior to analyzing.
    • Mark Chao's avatar
      Update merge request's merge_commit for branch update · 1f7647f4
      Mark Chao authored
      Analyze new commits graph to determine each commit's merge commit.
      Fix "merged with [commit]" info for merge requests being merged
      automatically by other actions.
      Allow analyzing upto the relevant commit
    • Douglas Barbosa Alexandre's avatar
    • Oswaldo Ferreira's avatar
    • Toon Claes's avatar
      Fill project_repositories for hashed storage · 5237a55d
      Toon Claes authored
      This adds a background migration that will ensure all projects that
      are on hashed storage have a row in `project_repositories`.
      Related issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/48527
  11. 06 Dec, 2018 8 commits
  12. 05 Dec, 2018 6 commits