----

[[multiple-accounts-http]]
How do I use multiple accounts with the same hosting provider using HTTP?::
	Usually the easiest way to distinguish between these accounts is to use
	the username in the URL.  For example, if you have the accounts `author`
	and `committer` on `git.example.org`, you can use the URLs
	https://author@git.example.org/org1/project1.git and
	https://committer@git.example.org/org2/project2.git.  This way, when you
	use a credential helper, it will automatically try to look up the
	correct credentials for your account.  If you already have a remote set
	up, you can change the URL with something like `git remote set-url
	origin https://author@git.example.org/org1/project1.git` (see
	linkgit:git-remote[1] for details).

[[multiple-accounts-ssh]]
How do I use multiple accounts with the same hosting provider using SSH?::
	With most hosting providers that support SSH, a single key pair uniquely
	identifies a user.  Therefore, to use multiple accounts, it's necessary
	to create a key pair for each account.  If you're using a reasonably
	modern OpenSSH version, you can create a new key pair with something
	like `ssh-keygen -t ed25519 -f ~/.ssh/id_committer`.  You can then
	register the public key (in this case, `~/.ssh/id_committer.pub`; note
	the `.pub`) with the hosting provider.
+
Most hosting providers use a single SSH account for pushing; that is, all users
push to the `git` account (e.g., `git@git.example.org`).  If that's the case for
your provider, you can set up multiple aliases in SSH to make it clear which key
pair to use.  For example, you could write something like the following in
`~/.ssh/config`, substituting the proper private key file:
+
----
# This is the account for author on git.example.org.
Host example_author
	HostName git.example.org
	User git
	# This is the key pair registered for author with git.example.org.
	IdentityFile ~/.ssh/id_author
	IdentitiesOnly yes
# This is the account for committer on git.example.org.
Host example_committer
	HostName git.example.org
	User git
	# This is the key pair registered for committer with git.example.org.
	IdentityFile ~/.ssh/id_committer
	IdentitiesOnly yes
----
+
Then, you can adjust your push URL to use `git@example_author` or
`git@example_committer` instead of `git@example.org` (e.g., `git remote set-url
git@example_author:org1/project1.git`).

Transfers
---------

[[sync-working-tree]]
How do I sync a working tree across systems?::
	First, decide whether you want to do this at all.  Git works best when you
	push or pull your work using the typical `git push` and `git fetch` commands
	and isn't designed to share a working tree across systems.  This is
	potentially risky and in some cases can cause repository corruption or data
	loss.
+
Usually, doing so will cause `git status` to need to re-read every file in the
working tree.  Additionally, Git's security model does not permit sharing a
working tree across untrusted users, so it is only safe to sync a working tree
if it will only be used by a single user across all machines.
+
It is important not to use a cloud syncing service to sync any portion of a Git
repository, since this can cause corruption, such as missing objects, changed
or added files, broken refs, and a wide variety of other problems.  These
services tend to sync file by file on a continuous basis and don't understand
the structure of a Git repository.  This is especially bad if they sync the
repository in the middle of it being updated, since that is very likely to
cause incomplete or partial updates and therefore data loss.
+
An example of the kind of corruption that can occur is conflicts over the state
of refs, such that both sides end up with different commits on a branch that
the other doesn't have.  This can result in important objects becoming
unreferenced and possibly pruned by `git gc`, causing data loss.
+
Therefore, it's better to push your work to either the other system or a central
server using the normal push and pull