Re: bare vs non-bare <1.7 then >=1.7 ?

From: Enrico Weigelt <enrico.weigelt@vnc.biz>
Date: Nov 10, 2012, 08:23 UTC
Message-ID: <e4dc73e8-69f9-4695-b8f7-cbc0f04e8197@zcs>
In-Reply-To: <509B8552.4080303@rktmb.org>

Show 5 quoted lines

> 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
> one.
> Searchin for some explanations, I found this ressource:
> http://www.bitflop.com/document/111

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) some server:

 * 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>

cu

-- 
Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

enrico.weigelt@vnc.biz; www.vnc.de