On Wed, Jun 16 2021, Bagas Sanjaya wrote: > On 15/06/21 23.17, Ævar Arnfjörð Bjarmason wrote: >> -Suppose that Alice has started a new project with a Git repository in >> -/home/alice/project, and that Bob, who has a home directory on the >> -same machine, wants to contribute. >> +Suppose that you've started a new project with a Git repository in >> +/home/you/project, and you'd like another user on the same local >> +machine to be able to contribute to it. E.g. a www-data user to serve >> +the content up with a webserver. >> -Bob begins with: >> +As the `www-data` user do: >> > ------------------------------------------------ >> -bob$ git clone /home/alice/project myrepo >> +www-data$ git clone /home/you/project /var/www-data/deployment >> ------------------------------------------------ >> > > This assumes that we're on Debian or its derivatives, however many > users run Git on other distributions (Fedora, Arch, Gentoo, openSUSE, > etc.), so `www-data` user may not be present there. Also, `www-data` > is system account, as opposed to normal user account, so you can't log > in to it; you need as root `chown -R www-data:www-data /somewhere/`. > > This also assumes that we use Apache HTTPD. The setup for other > webservers may be different. For example, if NGINX is used (installed > from upstream packages rather than from Debian package repository), > you need to make site root (the path specified in `root` directive) > readable by `nginx` user. I meant www-data merely as an example, the user is expected to fill in the blanks as Junio noted downthread. Not all *nix systems even have $HOME in /home. But clearly it's confusing to some, do you think calling it s/www-data/website/g and otherwise making it non-distro specific would be better? >> -This creates a new directory "myrepo" containing a clone of Alice's >> +This creates a new directory "deployment" containing a clone of your >> repository. The clone is on an equal footing with the original >> project, possessing its own copy of the original project's history. >> > > But the scenario is we're cloning from local repo, so `git clone` here > implies --local (and bypasses normal Git transport mechanism), so to > get clone experience similar to when using remote repo, we can use > --no-local instead. Well spotted, I believe that was the behavior when this was writen at 927a503cd0 (New tutorial, 2006-01-22), so this bug has probably always been there... >> -Bob then makes some changes and commits them: >> +As `www-data` you then makes some changes and commit them: >> ------------------------------------------------ >> (edit files) >> -bob$ git commit -a >> +www-data$ git commit -a >> (repeat as necessary) >> ------------------------------------------------ >> -When he's ready, he tells Alice to pull changes from the >> repository >> -at /home/bob/myrepo. She does this with: >> +You can then pull those changes to the checkout in your home directory >> +at /home/you/project: >> ------------------------------------------------ >> -alice$ cd /home/alice/project >> -alice$ git pull /home/bob/myrepo master >> +you$ cd /home/you/project >> +you$ git pull /var/www-data/deployment master >> ------------------------------------------------ >> > > The resulting rewrite until this point makes no sense for > me. Previously we have Alice and Bob working the project, but now you > do the same, one as normal user account and one as system user > `www-data`. Honestly I would like keeping the status quo. Collectively we're a sample size of two, so it doesn't say much either way, but FWIW I've worked at two companies in the past that had some version of the pattern discussed in this article. I.e. you'd login to some machine, have a repo in $HOME, and used that as your staging area to another repo on the same machine also under your control (either permanently or exclusively, or you'd "lock" it for the duration). I don't think I've once in all my time using git been in the position to be logged into a machine, and pulling/pushing to another repo in someone else's $HOME or equivalent. In any case, I do think for the purposes of the example in the guide replacing Alice & Bob with You & another version of you removes a lot of potential confusion, we don't need to cover permissions, the other user doing unexpected things like non-ff updates, pruning branches you may have relied on through the --local clone etc. It's implicit that both "users" are you, so we only have to discuss the point of the actual example, how to pull and push between two different repos, the "different users" in this case was always a distraction.
