forum/receiving indirect renames on direct repo ?git-annexhttp://git-annex.branchable.com/forum/receiving_indirect_renames_on_direct_repo___63__/git-annexikiwiki2013-11-27T22:47:37Zcomment 1http://git-annex.branchable.com/forum/receiving_indirect_renames_on_direct_repo___63__/comment_1_f4b0a14373c75cb752597c832e296bcc/joeyh.name2013-11-27T22:47:37Z2013-10-26T19:35:46Z
<p>You should <strong>never, ever, ever</strong> run <code>git pull</code>, or <code>git checkout</code> inside a direct repository. You need to read <a href="http://git-annex.branchable.com/direct_mode/">direct mode</a>. If you do not fully understand it, you should avoid running any git commands that are not <code>git annex foo</code> in a direct mode repository. If you forget and do run such git commands, you can generally recover by running <code>git annex fsck</code>, although it's possible that the git command you run overwrites your only copy of a file, and so you'd lose it.</p>
<pre>
To ssh://michele@home/home/michele/casa
6c18669..8cc74a0 git-annex -> synced/git-annex
! [rejected] master -> synced/master (non-fast-forward)
error: failed to push some refs to 'ssh://michele@home/home/michele/casa'
</pre>
<p>I'll bet that if you look at the <code>git config</code> of this repository it failed to push to, you'll find that it has <code>receive.denyNonFastforwards</code> set to true. If you unset that, the push should work.</p>
still cannot push when remote has renameshttp://git-annex.branchable.com/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53/Michele2013-11-27T22:47:37Z2013-10-27T23:06:03Z
<p>now, I went again through docs, and i realized how stupid was issuing a git pull on a direct repo. thanks for your patience.</p>
<p>but, i double checked the configuration, I assume "receive.denyNonFastForwards" is false by default, but anyway I set it up explicitely so that now my git config (on the linux indirect repo - with respect to my previous example, I got rid of the "extra" bare repo in the middle) shows:</p>
<pre><code>$ git config --list
user.email=m@g.com
user.name=michele
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
annex.uuid=d084e0fd-95a7-4c98-a206-fbf2c85b779d
annex.version=3
receive.denynonfastforwards=false
</code></pre>
<p>still I am receiving the push refusal:</p>
<pre><code>M:\win>git annex sync
commit
ok
pull origin
ok
push origin
To ssh://michele@home/home/michele/casa
! [rejected] master -> synced/master (non-fast-forward)
error: failed to push some refs to 'ssh://michele@home/home/michele/casa'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and merge the remote changes
hint: (e.g. 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
failed
git-annex: sync: 1 failed
</code></pre>
<p>Same happens with a bare repository in the middle. BTW: the windows "client" repository is behind NAT, so that the linux indirect doesn't actively sync against it: could that be source of the problem ?</p>
possible explanationhttp://git-annex.branchable.com/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5/Michele2013-11-27T22:47:37Z2013-10-29T11:56:21Z
<p>now, i tried to understand what happens. Instead of issuing the <em>git annex sync</em>, I relied on <em>git pull origin, git merge origin/master</em>, (I red <a href="http://git-annex.branchable.com/forum/Help_Windows_walkthrough/">http://git-annex.branchable.com/forum/Help_Windows_walkthrough/</a> and I assume that pull origin / merge origin/master would work similarly to the "download" part of sync, <em>except for losing all my direct content</em>) just to understand what was going on, with a clarifying result:</p>
<p>while git annex sync fails on push, git pull origin fails on pull:</p>
<pre><code>M:\win>git pull origin
Updating 5408d6f..c566a69
error: Your local changes to the following files would be overwritten by merge:
myfile
Please, commit your changes or stash them before you can merge.
Aborting
</code></pre>
<p>note that the file has not been modified locally (just got it through git annex get).
issuing a git diff, reveals:</p>
<pre><code>M:\win>git diff myfile
diff --git a/myfile b/myfile
index beaf3e8..dc5b4ff 120000
--- a/myfile
+++ b/myfile
@@ -1 +1 @@
-.git/annex/objects/z5/v7/SHA256E-s8--6090923ed0931dcc6699f32fb66fa4ba32c10924088b12c66fb4ce35a91ba98c/SHA256E-s8\ No newline at end of file
+linux.1
(END)
</code></pre>
<p>ok, i follow suggestion, and I perform a git stash. that still wouldn't suffice for git annex sync:</p>
<pre><code>M:\win>git annex sync
commit
ok
pull origin
ok
push origin
To ssh://michele@home/home/michele/homebase
! [rejected] master -> synced/master (non-fast-forward)
error: failed to push some refs to 'ssh://michele@home/home/michele/homebase'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and merge the remote changes
hint: (e.g. 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
failed
git-annex: sync: 1 failed
</code></pre>
<p>now, i can perform instead a <em>git pull origin</em>, since I am confident my content is stashed.</p>
<pre><code>M:\win>git pull origin
Updating 5408d6f..c566a69
Fast-forward
myfile => myfile.renamed | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename myfile => myfile.renamed (100%)
</code></pre>
<p>merge is not doing anything more: at this stage content has gone (file is a direct-mode symlink nad it cannot be fixed by fsck).
But i can recover it from stash (and I must do it unless I want to get the annex to think i still have content).</p>
<pre><code>git stash apply
</code></pre>
<p>voilĂ : the content is there! and the repos seems in good order.
this only adds up that this is possibily a bug in the fact that git reports direct content as modified when indeed it hasn't been modified: but this affects git annex sync only when merging renaming files.
git annex sync now works perfectly .</p>
<p>to sum it up, I have two questions:</p>
<p>1) does using stash to circumvent the problem expose me to any risk ?
2) would the behaviour on receiving renames in the abovementioned situation worth to be signaled as a bug ?</p>