> When experimenting in order to train some colleagues, I saw that If I
> clone a repository, I couldn't push to it because it was a non-bare
> Searchin for some explanations, I found this ressource:
That's just a precaution (technically it's not necessary, just stops
you from doing some dumb things). Suppose the following scenario:
* non-bare repository A, with branch 'master' currently checked out.
* clone B -> somebody's working on branch 'master' (which was forked
from A's master)
* on A, somebody did some local changes
* meanwhile somebody pushes the branch 'master' from B to A
* after that, on A, new commit to 'master'.
Weird things can happen, eg. the changes coming from B completely
reverted by the new commit in A.
Unless nobody pushes to the branch currently checked and later somebody
doing local changes after that, there shouldn't be any real technical
problem. But then, you most likely wont need an worktree anyways.
Wait, there *is* an usecase for such things, deploying trees (eg. webapps)
* application is developed in git
* the final production-system tree is maintained in certian branch
* a post-update hook acts on a specific production branch and does
something like git checkout --detach <treeish>
Mit freundlichen Grüßen / Kind regards
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html