Joey Hess [Wed, 18 Nov 2020 18:48:50 +0000 (14:48 -0400)]
newline mode (mis)handling for windows
Unfortunately, there is no hGetNewLineMode. This seems like an oversight
that should be fixed in ghc, but for now, I paper over it with a windows
hack.
Joey Hess [Wed, 18 Nov 2020 18:21:47 +0000 (14:21 -0400)]
working hGetLineUntilExitOrEOF
The problem with the old version seemed to be that hWaitForInput blocks
rather than timing out when being run concurrently with hGetLine on the
same handle.
This passes the bench test, and also works when run concurrently on
different handles.
Joey Hess [Wed, 18 Nov 2020 16:23:15 +0000 (12:23 -0400)]
bench test for hGetLineUntilExitOrEOF
This seems to show that hWaitForInput does not seem to behave as
documented. It does not time out, so blocks forever in this situation.
This is with a 0 timeout and with larger timeouts. Unsure why, it looked
like it should work.
Joey Hess [Mon, 16 Nov 2020 18:09:55 +0000 (14:09 -0400)]
annex.adjustedbranchrefresh
Added annex.adjustedbranchrefresh git config to update adjusted branches
set up by git-annex adjust --unlock-present/--hide-missing.
Note, in a few cases, I was not able to make the adjusted branch
be updated in calls to moveAnnex, because information about what
file corresponds to a key is not available. They are:
* If two files point to one file, then eg, `git annex get foo` will
update the branch to unlock foo, but will not unlock bar, because it
does not know about it. Might be fixable by making `git annex get
bar` do something besides skipping bar?
* git-annex-shell recvkey likewise (so sends over ssh from old versions
of git-annex)
* git-annex setkey
* git-annex transferkey if the user does not use --file
* git-annex multicast sends keys with no associated file info
Doing a single full refresh at the end, after any incremental refresh,
will deal with those edge cases.
Joey Hess [Mon, 16 Nov 2020 15:21:33 +0000 (11:21 -0400)]
split out Annex.Content.Presence
This will let a module that Annex.Content imports use inAnnex.
Unsure yet if I will need that, but this split still seems to make
sense, and Annex.Content was way too long so splitting it is good.
Joey Hess [Mon, 16 Nov 2020 14:09:25 +0000 (10:09 -0400)]
support parsing numeric git configs as bool
I'm not sure if git documents it aside from 0 and 1, but any integer
can be interpreted as a bool by it. Doing the same in git-annex is good
for consistency. Also, I am planning a config that starts out as a
numeric range, but will later transition to a simple bool (hopefully),
which this interpretation supports well.
Joey Hess [Fri, 13 Nov 2020 18:32:06 +0000 (14:32 -0400)]
rename to --unlock-present and better reverse adjusting
An --unlock-present branch reverses back to a branch where
all files that get modified or renamed become locked, even if they were
originally unlocked. This is the same that reversing a --unlock branch
works, and the new name makes that commonality more clear.
Joey Hess [Fri, 13 Nov 2020 17:49:12 +0000 (13:49 -0400)]
add a test case that move respects numcopies
There is already one for drop, but move and drop don't handle numcopies
exactly the same, and there was recently a reversion in it checking
numcopies properly at all.
This commit was sponsored by Noam Kremen on Patreon.
Joey Hess [Fri, 13 Nov 2020 17:27:03 +0000 (13:27 -0400)]
git-annex adjust --lock-missing
Like --hide-missing the branch does not get updated when content
availability changes.
Seems to basically work, but sync does not update it yet.
Also, when a file is present and so unlocked, git mv followed by
git-annex sync results in the basis branch being updated to contain the
file with the new name, unlocked. This seems different than what
happens in an adjusted unlocked branch, where the commit propigates back
locked. Probably the reverse adjustment code needs to be improved to
handle this case.
Joey Hess [Thu, 12 Nov 2020 18:08:13 +0000 (14:08 -0400)]
examinekey: Added --migrate-to-backend
Note that, the way the SeekInput parser is written to support batch mode,
it's actually possible to do git-annex examinekey
"SHA1--foo foo.tar.gz" --migrate-to-backend=SHA1E
While that might be kind of useful to support multiple migrations not using
batch mode, I have not documented it. It would be better to take pairs of
key and file in that case.
Joey Hess [Tue, 10 Nov 2020 16:10:51 +0000 (12:10 -0400)]
add warning on add of annex link
Warn when adding a annex symlink or pointer file that uses a key that is
not known to the repository, to prevent confusion if the user has copied it
from some other repository.
This commit was sponsored by Jake Vosloo on Patreon.
Joey Hess [Mon, 9 Nov 2020 19:12:08 +0000 (15:12 -0400)]
use MatchingKey when a Key is known
This fixes a bug where a file that was not preferred content could be
transferred to a remote. This happened when the file got deleted after
the sync started running.
The only time checkMatcher is run without a Key is in calls to
checkFileMatcher, which are only done by add, addurl, import, and
smudge --clean. Those won't be affected by this kind of race. Anything
else that might be precaching and have a similar race as sync will also
be fixed, but I don't know if it actually affected anything other than
sync.
As well as fixing a bug, this also probably makes sync and --auto faster
by avoiding the redundant key lookup.
This commit was sponsored by Graham Spencer on Patreon.
projects / git-annex.git / log