| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Only fsck and reinject and the test suite used the Backend, and they can
look it up as needed from the Key. This simplifies the code and also speeds
it up.
There is a small behavior change here. Before, all commands would warn when
acting on an annexed file with an unknown backend. Now, only fsck and
reinject show that warning.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
http://git-annex.branchable.com/bugs/Unicode_file_names_ignored_on_Windows/
Not a complete fix yet.
|
| |
|
|
| |
UUIDBased is just a MapLog with a UUID for the field.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regular git file.
This is a new feature, it was not handled before, since it's a bit of an
edge case. However, it can be handled exactly the same as a file/dir
conflict, just leave the non-annexed item alone.
While implementing this, the core resolveMerge' function got a lot simpler
and clearer. Note especially that where before there was an asymetric call to
stagefromdirectmergedir, now graftin is called symmetrically in both cases.
And, in order to add that `graftin us`, the current branch needed to be
known (if there is no current branch, there cannot be a merge conflict).
This led to some cleanups of how autoMergeFrom behaved when there is no
current branch.
This commit was sponsored by Philippe Gauthier.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I think that f5ce1a15d7a35b85ffa938ee950f4749bf445939 didn't quite manage
to actually fix the bug, although I have not checked since its "fix" got
redone.
The test suite now actually checks the file staged in git is a symlink,
rather than relying on the bug casing a later sync failure. This seems a
more reliable way to detect it, and probably avoids a heisenbug in the test
suite.
|
| |
|
|
|
| |
The test case that was supposed to cover this did not.. It is for some
other bug, which is apparently a bit of a heisenbug.
|
| |
|
|
| |
Let through HOME, etc when running git-annex from test suite.
|
| | |
|
| |
|
|
| |
be extracted from it
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(And a vpop command, which is still a bit buggy.)
Still need to do vadd and vrm, though this also adds their documentation.
Currently not very happy with the view log data serialization. I had to
lose the TDFA regexps temporarily, so I can have Read/Show instances of
View. I expect the view log format will change in some incompatable way
later, probably adding last known refs for the parent branch to View
or something like that.
Anyway, it basically works, although it's a bit slow looking up the
metadata. The actual git branch construction is about as fast as it can be
using the current git plumbing.
This commit was sponsored by Peter Hogg.
|
| | |
|
| |
|
|
|
|
|
|
| |
Promosing work toward metadata driven filter branches. A few methods
to construct them are stubbed out; all the data types and pure code
seems good.
This commit was sponsored by Walter Somerville.
|
| | |
|
| |
|
|
|
|
|
| |
A very haskell commit! Just data types, instances to serialize the metadata
to a nice format, and QuickCheck tests.
This commit was sponsored by Andreas Leha.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
git-annex has been using MissingH's `abdNormPath` forever, but that's
unmaintained and possibly buggy, and doesn't work on Windows. I've been
wanting to get rid of it for some time, and finally did today, writing a
`simplifyPath` that does the things git-annex needs and will work with all
the Windows filename craziness, and takes advantage of the more modern
System.FilePath to be quite a simple peice of code. A QuickCheck test found
no important divergences from absNormPath. A good first step to making
git-annex not depend on MissingH at all.
And it fixed some weird behaviors on Windows like
`git annex add ..\subdir\file` not working.
Note that absNormPathUnix has been left alone for now.
|
| |
|
|
|
| |
Note: Test reordered because running git-annex sync early broke the
environment for some other tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix bug in automatic merge conflict resolution code when used
on a filesystem not supporting symlinks, which resulted in it losing
track of the symlink bit of annexed files.
This was the underlying bug that was causing another test to fail,
which got worked around in f5d0c8f0bf7f018479eb4da7e8c41598b7aacb7d.
I've chosen to keep 2 separate test cases since the old test case only
detected the problem accidentially.
Test suite passes on FAT & in windows, as well as on proper unix systems.
This commit was sponsored by Ellis Whitehead.
|
| | |
|
| |
|
|
|
|
| |
This adds a test for a failure mode seemingly specific to Windows
that was removed in f5d0c8f0bf7f018479eb4da7e8c41598b7aacb7d, and puts it
in its own test case.
|
| |
|
|
|
|
|
|
|
| |
This fixes the problem of the environment variables apparently not being
seen on Windows. I could probably remove the setting of the env vars from
Test.hs now as this covers it better.
Note that outside the test suite, git-annex on windows seems to manage to
configure the repo so commits work on its own.
|
| |
|
|
|
|
| |
f5d0c8f0bf7f018479eb4da7e8c41598b7aacb7d broke the mixed conflict
resolution test. Since origin is no longer involved, both sides have to
sync after pairing. (The sync before pairing is just to get a commit.)
|
| |
|
|
| |
A broken symlink would cause the mode setting to fail.
|
| | |
|
| |
|
|
|
|
|
| |
On windows, the sync of the second cloned repo to origin failed, because
synced/master was a non-fast-forward. This may be a bug of its own, but
it's not the issue that this test was intended to test, so disconnect
the repos from origin before syncing.
|
| | |
|
| |
|
|
|
|
| |
On Windows, a file that is not writable cannot be deleted even if in a
directory with write perms. So git object files were not getting deleted
when removing a git repository.
|
| |
|
|
| |
Opened a bug about this: https://github.com/jystic/unix-compat/issues/10
|
| |
|
|
| |
This reverts commit 65eb61a902ecf68da69d774063fea4880f619a13.
|
| |
|
|
|
|
| |
revert 852f1f6cea85a7c781c8286f459023bdacebe021
tasty-rerun is stuck in NEW in debian
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This will be used in expiring old unused objects. The timestamp is when it
was first noticed it was unused.
Backwards compatability: It supports reading old format unused log files.
The old version of git-annex will ignore lines in log files written by the
new version, so the worst interop problem would be git annex dropunused not
knowing some numbers that git-annex unused reported.
|
| |
|
|
|
|
| |
have run
Should be ready now for tasty-rerun.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* numcopies: New command, sets global numcopies value that is seen by all
clones of a repository.
* The annex.numcopies git config setting is deprecated. Once the numcopies
command is used to set the global number of copies, any annex.numcopies
git configs will be ignored.
* assistant: Make the prefs page set the global numcopies.
This global numcopies setting is needed to let preferred content
expressions operate on numcopies.
It's also convenient, because typically if you want git-annex to preserve N
copies of files in a repo, you want it to do that no matter which repo it's
running in. Making it global avoids needing to warn the user about gotchas
involving inconsistent annex.numcopies settings.
(See changes to doc/numcopies.mdwn.)
Added a new variety of git-annex branch log file, that holds only 1 value.
Will probably be useful for other stuff later.
This commit was sponsored by Nicolas Pouillard.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I've had one or two fails sent to me involving cases QuickCheck didh't
easily find, and tasty makes this easy.
|
| | |
|
Joey Hess