initial pass
This commit is contained in:
parent
4f88bc87a5
commit
53d9b0fc5f
1 changed files with 56 additions and 0 deletions
|
@ -0,0 +1,56 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2016-05-23T17:30:07Z"
|
||||
content="""
|
||||
I've now got a copy of the repo, in
|
||||
~/lib/big/git-annex-test-repos/ssl.zerodogg.org__zerodogg_private_tmp_privateDocs.zerodogg.tar.xz.gpg
|
||||
|
||||
Looking at commit 77c7d149646655fb5851c3db584fe70d64707d04, it merges in
|
||||
0b4896bc205696630c81cf557959a4aaa24906f0 which has an empty tree.
|
||||
|
||||
0b4896bc205696630c81cf557959a4aaa24906f0 is itself a merge commit.
|
||||
Both of the commits it merges themselves have empty trees.
|
||||
And so it goes down quite a way, with empty merge commits including
|
||||
418367b, 7bab5cf, b651554, cf5de84, c5905f7, 928040e, a590245, 5b53fc9,
|
||||
6d9f5da, 5f2623d. The freqency of these might indeed indicate some kind
|
||||
of feedback loop, but I don't think whatever is causing that is the core problem.
|
||||
|
||||
fc6670a37fd9d3984a112a80d9bbaec5c041c005 is the crucial merge it seems. Its
|
||||
parents are 71b6c8a and f8dfc21. Both of those parents have the same tree,
|
||||
5f18bed323c29fb77add3a84abcf8b1fb6b646d7, and that tree is populated with all
|
||||
the files. But somehow this merge deleted everything.
|
||||
|
||||
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
|
||||
parent 71b6c8ad3fc44926c9be2bbb1bd308592b6eb05c
|
||||
parent f8dfc219a40b2871baed3192ea5806bb4ac551e7
|
||||
author xxx 1463570165 +0200
|
||||
committer xxx 1463570165 +0200
|
||||
|
||||
Merge branch 'refs/heads/synced/master' into HEAD
|
||||
|
||||
(There are empty trees earlier where the same thing happened that you
|
||||
reverted, but it seems best to focus on the most recent occurance.)
|
||||
|
||||
So, can you find fc6670a in .git/annex/daemon.log* in any of the
|
||||
clones of this repository? It would be good to narrow down on which
|
||||
machine(s) the bad merge is happening. (Maybe you've already narrowed it down?)
|
||||
|
||||
One of the two parent commits (71b6c8ad3fc44926c9be2bbb1bd308592b6eb05c)
|
||||
is a manual revert you did, the other commit looks to have been done by
|
||||
the assistant.
|
||||
I'm guessing that refs/heads/synced/master was f8dfc219a40b2871baed3192ea5806bb4ac551e7
|
||||
when the bad merge was generated. So this bad merge probably happened in
|
||||
the repository where you did that manual reversion.
|
||||
|
||||
As far as I can tell this was a regular git merge that somehow decided to empty
|
||||
the tree. It was not a case of git-annex auto-resolving a merge conflict.
|
||||
|
||||
Are you using adjusted branches in any of the clones of this repository?
|
||||
|
||||
What version(s) of git are being used?
|
||||
|
||||
(I noticed that despite using v6 mode, every file in the repository
|
||||
seems to be locked, so the smudge filters etc should not be involved in the
|
||||
problem unless using an adjusted branch.)
|
||||
"""]]
|
Loading…
Add table
Reference in a new issue