summaryrefslogtreecommitdiff
path: root/doc/bugs/sync_in_adjusted_branch_deleted_recently_added_files.mdwn
blob: 8c4425f8b0cfed4cc809b36c24dc61aae67e6fac (plain)
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
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.

--[[Joey]]