1. 31 Oct, 2018 2 commits
  2. 22 Oct, 2018 2 commits
    • Duy Nguyen's avatar
      revision.c: better error reporting on ref from different worktrees · ab3e1f78
      Duy Nguyen authored
      Make use of the new ref aliases to pass refs from another worktree
      around and access them from the current ref store instead. This does
      not change any functionality, but when a problem arises, we would like
      the reported messages to mention full ref aliases, like this:
          fatal: bad object worktrees/ztemp/HEAD
          warning: reflog of 'main-worktree/HEAD' references pruned commits
      instead of
          fatal: bad object HEAD
          warning: reflog of 'HEAD' references pruned commits
      which does not really tell where the refs are from.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Duy Nguyen's avatar
      refs: new ref types to make per-worktree refs visible to all worktrees · 3a3b9d8c
      Duy Nguyen authored
      One of the problems with multiple worktree is accessing per-worktree
      refs of one worktree from another worktree. This was sort of solved by
      multiple ref store, where the code can open the ref store of another
      worktree and has access to the ref space of that worktree.
      The problem with this is reporting. "HEAD" in another ref space is
      also called "HEAD" like in the current ref space. In order to
      differentiate them, all the code must somehow carry the ref store
      around and print something like "HEAD from this ref store".
      But that is not feasible (or possible with a _lot_ of work). With the
      current design, we pass a reference around as a string (so called
      "refname"). Extending this design to pass a string _and_ a ref store
      is a nightmare, especially when handling extended SHA-1 syntax.
      So we do it another way. Instead of entering a separate ref space, we
      make refs from other worktrees available in the current ref space. So
      "HEAD" is always HEAD of the current worktree, but then we can have
      "worktrees/blah/HEAD" to denote HEAD from a worktree named
      "blah". This syntax coincidentally matches the underlying directory
      structure which makes implementation a bit easier.
      The main worktree has to be treated specially because well... it's
      special from the beginning. So HEAD from the main worktree is
      acccessible via the name "main-worktree/HEAD" instead of
      "worktrees/main/HEAD" because "main" could be just another secondary
      This patch also makes it possible to specify refs from one worktree in
      another one, e.g.
          git log worktrees/foo/HEAD
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  3. 15 Aug, 2018 1 commit
  4. 12 Feb, 2018 2 commits
  5. 24 Jan, 2018 1 commit
  6. 16 Oct, 2017 1 commit
  7. 24 Aug, 2017 1 commit
    • Duy Nguyen's avatar
      revision.c: --all adds HEAD from all worktrees · d0c39a49
      Duy Nguyen authored
      Unless single_worktree is set, --all now adds HEAD from all worktrees.
      Since reachable.c code does not use setup_revisions(), we need to call
      other_head_refs_submodule() explicitly there to have the same effect on
      "git prune", so that we won't accidentally delete objects needed by some
      other HEADs.
      A new FIXME is added because we would need something like
          int refs_other_head_refs(struct ref_store *, each_ref_fn, cb_data);
      in addition to other_head_refs() to handle it, which might require
          int get_submodule_worktrees(const char *submodule, int flags);
      It could be a separate topic to reduce the scope of this one.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  8. 25 Apr, 2017 1 commit
  9. 12 Dec, 2016 1 commit
    • Stefan Beller's avatar
      worktree: check if a submodule uses worktrees · 1a248cf2
      Stefan Beller authored
      In a later patch we want to move around the the git directory of
      a submodule. Both submodules as well as worktrees are involved in
      placing git directories at unusual places, so their functionality
      may collide. To react appropriately to situations where worktrees
      in submodules are in use, offer a new function to query the
      a submodule if it uses the worktree feature.
      An earlier approach:
        "Implement submodule_get_worktrees and just count them", however:
        This can be done cheaply (both in new code to write as well as run time)
        by obtaining the list of worktrees based off that submodules git
        directory. However as we have loaded the variables for the current
        repository, the values in the submodule worktree
        can be wrong, e.g.
        * core.ignorecase may differ between these two repositories
        * the ref resolution is broken (refs/heads/branch in the submodule
          resolves to the sha1 value of the `branch` in the current repository
          that may not exist or have another sha1)
      The implementation here is just checking for any files in
      $GIT_COMMON_DIR/worktrees for the submodule, which ought to be sufficient
      if the submodule is using the current repository format, which we also
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  10. 28 Nov, 2016 2 commits
  11. 13 Jun, 2016 1 commit
  12. 04 Jun, 2016 2 commits
  13. 22 Apr, 2016 5 commits
  14. 08 Oct, 2015 2 commits
  15. 02 Oct, 2015 1 commit