| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
Because that allowed writing to symlinks of files that are not present,
which followed the link and put bad content in an object location.
fsck: Fix up .git/annex/object directory permissions.
This commit was sponsored by an anonymous bitcoin donor.
|
|
|
|
|
|
| |
conflicted merge resolution
For one thing, that breaks the test suite. May revisit later.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
setup of them is incomplete, or because the remote git repository is not a git-annex repository.
Complicated by such repositories potentially being repos that should have
an annex.uuid, but it failed to be gotten, perhaps due to the past ssh repo
setup bugs. This is handled now by an Upgrade Repository button.
|
|
|
|
|
|
|
|
| |
indirect mode because its permissions cannot be modified.
Adding the file moved it to the annex, and then tried to set the mode.
Error unwind then moved the file back, and so the watcher saw the file get
deleted and then added back, and so tried again..
|
|
|
|
| |
nonzero at the end.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This works for both direct and indirect mode.
It may need some performance tuning.
Note that unlike git status, it only shows the status of the work tree, not
the status of the index. So only one status letter, not two .. and since
files that have been added and not yet committed do not differ between the
work tree and the index, they are not shown. Might want to add display of
the index vs the last commit eventually.
This commit was sponsored by an unknown bitcoin contributor, whose
contribution as been going up lately! ;)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that direct mode sets core.bare=true, git's normal prohibition about
pushing into the currently checked out branch doesn't work.
A simple fix for this would be an update hook which blocks the pushes..
but git hooks must be executable, and git-annex needs to be usable on eg,
FAT, which lacks x bits.
Instead, enabling direct mode switches the branch (eg master) to a special
purpose branch (eg annex/direct/master). This branch is not pushed when
syncing; instead any changes that git annex sync commits get written to
master, and it's pushed (along with synced/master) to the remote.
Note that initialization has been changed to always call setDirect,
even if it's just setDirect False for indirect mode. This is needed because
if the user has just cloned a direct mode repo, that nothing has synced
with before, it may have no master branch, and only a annex/direct/master.
Resulting in that branch being checked out locally too. Calling setDirect False
for indirect mode moves back out of this branch, to a new master branch,
and ensures that a manual "git push" doesn't push changes directly to
the annex/direct/master of the remote. (It's possible that the user
makes a commit w/o using git-annex and pushes it, but nothing I can do
about that really.)
This commit was sponsored by Jonathan Harrington.
|
|
|
|
|
| |
This includes storing the current state of the HEAD ref, which git annex
sync is going to need, but does not make sync use it.
|
| |
|
|
|
|
| |
gcryptsetup had a bug that caused it to fail with permission denied.
|
|
|
|
| |
master branch.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Copies files out of the annex. This avoids an unannex of one file breaking
other files that link to the same content. Also, it means that the content
remains in the annex using up space until cleaned up with "git annex
unused".
(The behavior of unannex --fast has not changed; it still hard
links to content in the annex. --fast was not made the default because it
is potentially unsafe; editing such a hard linked file can unexpectedly
change content stored in the annex.)
|
| |
|
| |
|
|
|
|
|
| |
New --want-get and --want-drop options which can be used to test preferred
content settings. For example, "git annex find --in . --want-drop"
|
| |
|
| |
|
|
|
|
| |
to avoid contending with the user's desktop login process.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit 699a90bdc195a67c5aa5fca34fcaa07fb2b530ae.
My windows build environment was broken; reverted to backup.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This used to work, but now hsc2hs is failing with a usage message.
Since I have not changed my windows build environment at all, it must be
some change due to a change in the cabal file. Perhaps too make flags are
causing it to hit a windows command line length limit?
Anyway, these hsc files did nothing on Windows, so can be omitted and not
built to work around yet another epic windows weirdness.
|
|
|
|
| |
Experimentally, using the raw TopFilePath was right here.
|
|
|
|
|
|
|
|
|
| |
This actually fixes a bug; if pre-commit was run in a subdir, it would pass
relative files when updating the associated file maps, and so the maps
wouldn't update.
I don't think this bug happened in practice, due to the way pre-commit is
called by the hook. It happened to chdir to the top of the work tree.
|
| |
|
|
|
|
|
| |
git-merge's creation of file~HEAD type files did not make this especially
nice to do.
|
|
|
|
|
|
|
|
|
| |
annexed file, and the other side is a non-annexed file, or a directory.
Note that this case is only fully automatically resolved in direct mode.
In indirect mode, git merge moves the file to file~HEAD, and replaces it
with the directory, and leaves the file in unmerged state, and sync doesn't
yet change that.
|
|
|
|
|
| |
Mostly because it gives me an excuse and a hook to document the schedule
expression format.
|
|\ |
|
| |
| |
| |
| | |
checked for status.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
addurl: Improve message when adding url with wrong size to existing file.
Before the message suggested the url didn't exist.
Fixed handling of URL keys that have no recorded size. Before, if the key
has no size, the url also had to not declare any size, which was unlikely
and wrong, or it was taken to not exist. This probably would mostly affect
keys that were added to the annex with addurl --relaxed.
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
This reverts commit c0caa37187e9c062825dd6d5cb6be2dfa63bc7dd.
|
|
|
|
|
|
| |
Thought was that this would be faster than a map, since a vector can be
updated more efficiently. It turns out to not seem to matter; runtime and
memory usage are basically identical.
|
|
|
|
| |
Actually fixed 2 leaks, the tuple leak may have been older.
|
| |
|