How to grant read/write to specific user in any existent or future subdirectory of a given directory

Sadly, its a bug in zsh completion for git. You can find discussion on 'zsh' mailing list here.

Daniel Shahaf did provided a patch for '_git':

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 518e6d198..45a0fa622 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -6609,20 +6609,33 @@ __git_files_relative () {
 (( $+functions[__git_files] )) ||
 __git_files () {
   local compadd_opts opts tag description gitcdup gitprefix files expl
+  local pref

   zparseopts -D -E -a compadd_opts V: J: 1 2 n f X: M: P: S: r: R: q F:
   zparseopts -D -E -a opts -- -cached -deleted -modified -others -ignored -unmerged -killed x+: --exclude+:
   tag=$1 description=$2; shift 2

-  gitcdup=$(_call_program gitcdup git rev-parse --show-cdup 2>/dev/null)
-  __git_command_successful $pipestatus || return 1
+  case $(_call_program gitinworktree git rev-parse --is-inside-work-tree 2>/dev/null) in
+    (true)
+      gitcdup=$(_call_program gitcdup git rev-parse --show-cdup 2>/dev/null)
+      __git_command_successful $pipestatus || return 1

-  gitprefix=$(_call_program gitprefix git rev-parse --show-prefix 2>/dev/null)
-  __git_command_successful $pipestatus || return 1
+      gitprefix=$(_call_program gitprefix git rev-parse --show-prefix 2>/dev/null)
+      __git_command_successful $pipestatus || return 1
+
+      local pref=$gitcdup$gitprefix$PREFIX
+      ;;
+    (false)
+      local pref=
+      ;;
+    (*)
+      # XXX what to do?
+      return 1
+      ;;
+  esac

   # TODO: --directory should probably be added to $opts when --others is given.

-  local pref=$gitcdup$gitprefix$PREFIX

   # First allow ls-files to pattern-match in case of remote repository
   files=(${(0)"$(_call_program files git ls-files -z --exclude-standard ${(q)opts} -- ${(q)${pref:+$pref\\\*}} 2>/dev/null)"})
@@ -7585,7 +7598,8 @@ _git() {
         ;;
       (option-or-argument)
         curcontext=${curcontext%:*:*}:git-$words[1]:
-       (( $+opt_args[--git-dir] )) && local -x GIT_DIR=$opt_args[--git-dir]
+        (( $+opt_args[--git-dir] )) && local -x GIT_DIR=${(e)opt_args[--git-dir]}
+        (( $+opt_args[--work-tree] )) && local -x GIT_WORK_TREE=${(e)opt_args[--work-tree]}
        if ! _call_function ret _git-$words[1]; then
          if zstyle -T :completion:$curcontext: use-fallback; then
            _default && ret=0

It applies clearly to zsh 5.4.1 but it didn't work form me,YMMV.

I'll update this answer as the issue is being worked on.

EDIT:

With the above patch it does work, but where you put add is important - it has to be at the end:

git --git-dir=$HOME/.dotfiles --work-tree=$HOME/ add

One more thing worth noticing - its somewhat slow.

If you have a ssh agent running, do:

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...

That basically tells the git command started by root (or the ssh command started by that git command) to use your ssh agent (how to connect to it, which root should be able to as it has every right).

If you don't have a ssh agent running, you can start one beforehand with:

eval "$(ssh-agent)"

(and add keys to it as needed with ssh-add).

Alternatively, you can use

sudo -E git clone...

To pass every environment variable across sudo, not just $SSH_AUTH_SOCK.

I would not got with @NgOon-Ee's suggestion in comment to add $SSH_AUTH_SOCK to the env_keep list. In general, you don't want to pollute root's environment, as that's the user you start services as. For instance sudo sshd to start a sshd service would mean all ssh sessions started through that service would inherit your $SSH_AUTH_SOCK, polluting users environment with something they can't and shouldn't use. Even for other target users than root, passing that variable across would not make sense as the target user couldn't make use of that authentication agent.

Now, that only addresses key authentication. If you also wanted root to inherit your settings in your ~/.ssh/config, you could not do that with ssh environment variables, but you could do that with git environment variables. For instance, defining a sugit function as:

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
             -o User=$LOGNAME \
             -F ~$LOGNAME/.ssh/config" git "$@"
}

That is, tell git to use a ssh command that uses your ssh config file and agent and username instead of root's.

Or maybe even better, tell git to run ssh as the original user:

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}