bare repositoriesgit-annexhttp://git-annex.branchable.com/bare_repositories/git-annexikiwiki2016-10-26T18:08:08ZHow to convert bare repositories to non-barehttp://git-annex.branchable.com/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd/Ævar Arnfjörð2013-11-27T22:47:37Z2012-11-11T20:14:44Z
<p>I made a repository bare and later wanted to convert it, this would have worked with just plain git:</p>
<pre><code>cd bare-repo.git
mkdir .git
mv .??* * .git/
git config --unset core.bare
git reset --hard
</code></pre>
<p>But because git-annex uses different hashing directories under bare repositories all the files in the repo will point to files you don't have. Here's how you can fix that up assuming you're using a backend that assigns unique hashes based on file content (e.g. the SHA256 backend):</p>
<pre><code>mv .git/annex/objects from-bare-repo
git annex add from-bare-repo
git rm -f from-bare-repo
</code></pre>
push failshttp://git-annex.branchable.com/bare_repositories/comment_2_c88216da0588562c851c2ceabbfebc0a/BehemothTheCat2015-02-14T00:11:40Z2015-02-14T00:11:40Z
<p>These instructions don't work for me, unfortunately.</p>
<p>This step:</p>
<pre><code>git push origin master git-annex
</code></pre>
<p>results in:</p>
<pre><code>To ssh://my.server.com/home/itz/git/annex.git
! [rejected] git-annex -> git-annex (non-fast-forward)
error: failed to push some refs to 'ssh://my.server.com/home/itz/git/annex.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
</code></pre>
<p>Versions: git 1:1.9.1-1~bpo70+2 , git-annex 5.20141024~bpo70+1 (both packaged by Debian, same on local and remote)</p>
<p>And yes, I did a pull on the master branch first. Afraid to do anything
with the git-annex branch without explicit instruction.</p>
comment 3http://git-annex.branchable.com/bare_repositories/comment_3_26ba93bddb0cd1bb4e1799311f3ca750/joey2015-02-17T21:57:55Z2015-02-17T21:54:33Z
<p>Since the two repos git-annex branches have diverged, you need to run <code>git
annex merge</code> to merge them before you can push that branch.</p>
<p>Of course, <code>git annex sync</code> handles all that for you. It can be used
against a bare repository as well as a non-bare.</p>
Convert bare repository to normalhttp://git-annex.branchable.com/bare_repositories/comment_4_7cf6103709a7a2710686681a6f406214/Frederik Vanrenterghem2015-05-19T09:17:15Z2015-05-19T09:17:15Z
Just wondering what the right steps are to convert a bare repository to a normal one? The comment above from 2.5 years ago includes the creation of a .git directory, which actually already exists. Have things changed in the mean time?
comment 5http://git-annex.branchable.com/bare_repositories/comment_5_6328134497c0de6a088087fc9cb0e59e/anarcat [id.koumbit.net]2015-05-19T12:18:05Z2015-05-19T12:18:05Z
<p>Well, no, i don't think they changed, unless i missed something: there
shouldn't be a <code>.git</code> repository there.</p>
<p>There are <a href="http://stackoverflow.com/questions/10637378/how-do-i-convert-a-bare-git-repository-into-a-normal-one-in-place">various
instructions</a>
on how to do this online. They do seem to agree with the first comment
above.</p>
<p>Personnally, I would just <code>git clone</code> to a different repo and <code>git
annex forget</code> the old one. Unless you have a very complex repository
with a lot of files, this is simple enough... You could even use <code>git
annex reinit</code> to recycle the previous uuid if that's a concern. So in
short:</p>
<p> git clone repo.git repo
cd repo
git annex info --fast # find the UUID of repo.git
git annex move --from $UUID
git annex reinit $UUID</p>
<p>Then <code>repo.git</code> can be removed if you are certain everything is
correct in <code>repo</code>.</p>
<p>Note that you may want to have backups of everything before you do
anything, as usual.</p>
comment 6http://git-annex.branchable.com/bare_repositories/comment_6_bf227861ec3cb2ea474c143218c68133/Frederik Vanrenterghem2015-05-21T06:14:33Z2015-05-21T06:14:33Z
<p>Thanks Anarcat. I actually was dealing with a repository in direct mode, not bare mode. Only realised after today encountering one in bare mode, and reading <a href="http://git-annex.branchable.com/internals/">internals</a>. Your method worked too, but</p>
<pre><code>git annex indirect
</code></pre>
<p>would have been quicker I guess.</p>
synced/* branches necessary on bare repo?http://git-annex.branchable.com/bare_repositories/comment_7_9e065a2d8aaf7371ab7c0bb4f0c724b0/scottgorlin2016-10-18T21:17:40Z2016-10-18T21:17:40Z
<p>Are the synced/* branches necessary for a bare repo? Since there is no working directory, can't sync operate directly on the top level branches of choice, and avoid 'branch pollution'? Is it implemented this way just to simplify the code, or ...?</p>
<p>Also wondering if there is a practical difference between a bare repo and an rsync repo (other than storing the metadata, of course) - they both use rsync for transfer, no? Any speed/overhead/other differences to consider when choosing?</p>
<p>For my use case pertaining to question 2 I am using a local ARM NAS which works with the binary (plus S3 or gdrive remotes etc), but I figure why not spin up a private gitlab repo with metadata and no content since I want an off-site backup of the metadata anyways. Does a bare repo on a nas add anything here, vs an rsync remote? Perhaps just rsync is even better to avoid overhead on a tiny/slow NAS?</p>
comment 8http://git-annex.branchable.com/bare_repositories/comment_8_d4dff0d6265be941af9f66ba09f36ebe/joey2016-10-26T18:08:08Z2016-10-26T17:44:55Z
<p>@scottgorlin bare git repositories cannot in general be detected when
looking at a remote, so <code>git annex sync</code> picks a behavior that works
whether a remote is a bare git repository or not.</p>
<p>A bare repo and a rsync special remote should have pretty similar
performance.</p>