Joey Hess [Mon, 18 Nov 2019 20:09:09 +0000 (16:09 -0400)]
git-lfs: remember urls, and autoenable remotes using known urls
* git-lfs: The url provided to initremote/enableremote will now be
stored in the git-annex branch, allowing enableremote to be used without
an url. initremote --sameas can be used to add additional urls.
* git-lfs: When there's a git remote with an url that's known to be
used for git-lfs, automatically enable the special remote.
Joey Hess [Fri, 15 Nov 2019 16:01:30 +0000 (12:01 -0400)]
stop displaying rsync progress, and use git-annex's own progress display for local-to-local repo transfers
Reasons to do this include:
1. I've gotten pretty used to git-annex's own progress display, which is
used for all transfers over ssh (except to old git-annex-shell),
and for most special remote transfers. It's getting to seem weird to see
the rsync progress display instead.
2. When -J was used, the rsync output could not be shown, and so there was
no progress display. Now there will be.
Progress will also be displayed now when cp CoW is used. But I'd expect a CoW
copy to typically run so fast that the progress display will barely be
noticable.
Joey Hess [Thu, 14 Nov 2019 23:20:28 +0000 (19:20 -0400)]
fix GIT_EXEC_PATH to point to bundle/git-core
This makes it be the same as in the linux runshell.
It may be that bundle/ used to have all the necessary binaries in it,
but that seems unlikely. I think that the breakage fixed by my previous
commit masked this other breakage, and anything git execs from git-core
(as opposed to being buitin) has never worked in the OSX dmg.
Joey Hess [Thu, 14 Nov 2019 20:15:42 +0000 (16:15 -0400)]
OSX git-annex.app: Fix a regression that broke git-remote-https, git-remote-http, and git-shell
Putting the binaries in bundle/git-core/bin didn't work on OSX,
linker can't find the libraries next to those binaries where it expects to.
So instead put the binaries in the progDir.
Joey Hess [Thu, 14 Nov 2019 15:31:43 +0000 (11:31 -0400)]
Fix a crash (STM deadlock) when -J is used with multiple files that point to the same key
See the comment for a trace of the deadlock.
Added a new StartStage. New worker threads begin in the StartStage.
Once a thread is ready to do work, it moves away from the StartStage,
and no thread will ever transition back to it.
A thread that blocks waiting on another thread that is processing
the same key will block while in the StartStage. That other thread
will never switch back to the StartStage, and so the deadlock is avoided.
Joey Hess [Tue, 5 Nov 2019 16:41:15 +0000 (12:41 -0400)]
init: fix data loss bug
Fix bug that lost modifications to unlocked files when init is re-ran in an
already initialized repo.
In retrospect needing scanUnlockedFiles False in the direct mode upgrade
path was a good hint that it was unsafe when used with True.
However, this bug did not affect upgrade from v5. In such an upgrade, an
unlocked file that is modified is left as-is. The only place
scanUnlockedFiles True did overwrite modified unlocked files is during an
git-annex init of a repo that was already initialized by git-annex.
(I also tried a scenario where the repo had not been initialized by
git-annex yet, but was cloned from a v7 repo with an unlocked file, and the
pointer file replaced with some other content, and the data loss did not
occur in that situation.)
Since the fixed scanUnlockedFiles avoids overwriting non-pointer files,
it should be safe to run in any situation, so there's no need any longer
for the parameter.
projects / git-annex.git / log