2019-02-15 17:26:16 +00:00
|
|
|
Unfortunately, git-annex is completely broken in Windows right now:
|
|
|
|
|
|
|
|
* In a direct mode repository, `git annex add` stages the git-annex link,
|
|
|
|
but then `git annex sync` stages the file content into git, so the file
|
|
|
|
content gets committed to git.
|
|
|
|
* In a v7 repository (with or without adjusted branches), `git annex add`
|
|
|
|
stages the git-annex link, but `git status` then shows the file as
|
|
|
|
modified from what was staged, and `git diff --cached` shows a diff
|
|
|
|
from the git-annex link to the file content. And `git commit -a`
|
|
|
|
commits the file content to git, not to git-annex.
|
|
|
|
|
|
|
|
Something has bitrotted. Note that git-annex in Windows Subsystem for Linux
|
|
|
|
does not have these problems and seemed to work fairly well last time I
|
|
|
|
tried it. --[[Joey]]
|
|
|
|
|
|
|
|
These seem surprisingly related in some way, given that direct mode is only
|
|
|
|
being maintained and should not have changed its behavior at all.
|
|
|
|
Perhaps there has been some change that is causing both problems?
|
|
|
|
|
|
|
|
In direct mode, `git annex sync --content` is running "git add -f" on each
|
|
|
|
file in the work tree, including unmodified files and files that `git annex
|
|
|
|
add` has staged annex links for already. That's `stageDirect`, apparently
|
|
|
|
it falls through to the `addgit` action, that is supposed to only happen for
|
|
|
|
not yet staged files that are dummy symlinks or something (this code is
|
|
|
|
untouched since 2013). That suggests that `catKey` or `toInodeCache`
|
|
|
|
returned Nothing which should not happen in this case.
|
|
|
|
|
|
|
|
So, the next step will be to build git-annex on Windows and instrument
|
|
|
|
`stageDirect` to work out which thing it depends on has broken..
|
2019-02-18 22:06:35 +00:00
|
|
|
|
|
|
|
> [[fixed|done]] --[[Joey]]
|