1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
In my `big/git-annex-test-repos/20160830-annex-adjusted.tar.xz.gpg`,
I have a .git/ directory for a repo where `git annex sync` after `git annex add`
apparently committed the files and then fast-forward merged a branch
over top which did not contain the just-added files.
According to the bug reporter:
> As mentioned on IRC I switched to master, back to the adjusted
> branch and then did `git add "2016/H* T* und R*"` in the
> meantime after restoring the files from backup, but I have not
> synced/commited the latter yet. I also did `git gc` in the hope
> that it would reduce the size a bit, but to no real success :)
>
> My git-annex is 6.20160720-g9f0428e (standalone build) and git is
> 2.1.4-2.1+deb8u2 from jessie.
`git reflog` showed:
24a8128 HEAD@{3}: merge 24a81287ef63cd064977165b82de56e050c4a576: Fast-forward
9cdbd4f HEAD@{4}: commit: git-annex in orcus direct
9cdbd4f Adds the files, 24a8128 deletes them.
Where 9cdbd4f added the files, but then 24a8128 lost them.
The way 24a8128 appears in the reflog there is not what I usually see when
running `git annex sync` on an adjusted branch. Possible smoking gun?
Initial plan: Try to reset the adjusted branch and master back to before 9cdbd4f,
and re-run to try to reproduce this happening.
--[[Joey]]
----
Update: Was able to reproduce bug as follows:
1. Untar tarball
2. git reset --hard 961bbbf
3. git cherry-pick 9cdbd4f
4. git annex sync
Output of step #4 is:
On branch adjusted/master(unlocked)
nothing to commit, working tree clean
ok
merge synced/master (Merging into master...) Already up-to-date.
(Merging into adjusted branch...)
Updating 61bf677..46e18b7
Fast-forward
(diffstat shows 1 file added, and all files added by commit 9cdbd4f deleted)
Making changes other than that cherry-pick, like adding or renaming
a file, don't seem to trigger the bug.
I think that the bug is in Git.Tree.adjustTree, when the
addtreeitems are in a deep subdirectory, it seems to not be adding them
into the tree. This happens in simpler test cases, so something about
this particular tree is breaking the code.
----
Ok, think I found the bug. In Git.Tree.adjustTree, it grafts in the new
tree items, but it can forget that it needed to modify the tree, which
prevents the change from propigating up from the subtree to the root, and
so it gets left out of the reverse adjusted commit.
I'm committing a fix.
With the fix, when I git annex sync in felix's tree, the files that
were getting wrongly deleted are added. The commit summary shows
that git thinks those files were renamed:
rename 2016/xxx xxx und yyy/{ => 2016/xxx xxx und yyy}/zzz/P1230949.JPG (100%)
This seems wrong. I think this is a separate bug that was hidden
by the other one, it's grafting in files using their whole path,
to a subtree that is itself part way down that path.
---
A simpler case of the both bugs is to have a file like a/b/c/d already
committed and make a commit that adds a/b/x/y, without otherwise modifying
that tree. On an adjusted branch, `git annex sync` makes a commit of a tree
that does not include the new file. It may made a commit on top of it for
the adjusted branch that adds the file back, but the file doesn't reach
the master branch in this scenario.
--[[Joey]]
|
