git-annex/doc/bugs/windows_support_totally_bitrotted.mdwn
Joey Hess 1e95bc4fd1
avoid git warning about CRLF in restagePointerFile
Saw it on Windows, could probably also happen on linux with some
configuration. Since this is a pointer file, the warning does not apply.
2019-02-18 18:35:36 -04:00

31 lines
1.6 KiB
Markdown

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..
> [[fixed|done]] --[[Joey]]