| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
More accurately, it was supported already when map uses git-annex-shell,
but not when it does not.
Note that the user name cannot be shell escaped using git-annex's current
approach for shell escaping. I tried and some shells like dash cannot
cd ~'joey'. Rest of directory is still shell escaped, not for security but
in case a directory has a space or other weird character.
|
| |
|
|
| |
3.20111105, whenever the uuid.log is changed (ie, by init or describe).
|
| | |
|
| |
|
|
|
| |
Mostly only refactoring, but this does remove one redundant stat of the
symlink by copy.
|
| | |
|
| |
|
|
|
|
|
| |
files that are already present.
This can be a significant speedup when running in large trees that are
only missing a few files; it makes copy --from just as fast as get.
|
| | |
|
| | |
|
| |
|
|
|
| |
My testing involved widening the race by adding sleeps, and making sure
something sane happens in each case.
|
| | |
|
| | |
|
| |
|
|
|
| |
I've tested that this solves the cyclic drop problem.
Have not looked at cyclic move, etc.
|
| | |
|
| |
|
|
|
| |
This is needed for drop --from and move --from to check the lock,
as they do not use git-annex-shell inannex.
|
| |
|
|
|
|
|
|
| |
git-annex-shell inannex now returns always 0, 1, or 100 (the last when
it's unclear if content is currently in the index due to it currently being
moved or dropped).
(Actual locking code still not yet written.)
|
| |
|
|
|
| |
This is more safe than System.Cmd.Utils.safeSystem, since it does not throw
an error on nonzero exit status.
|
| |
|
|
|
|
|
| |
The lock will only persist during the perform stage, so the content must
be removed from the annex then, rather than in the cleanup stage.
(No lock is actually taken yet.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Many functions took the repo as their first parameter. Changing it
consistently to be the last parameter allows doing some useful things with
currying, that reduce boilerplate.
In particular, g <- gitRepo is almost never needed now, instead
use inRepo to run an IO action in the repo, and fromRepo to get
a value from the repo.
This also provides more opportunities to use monadic and applicative
combinators.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Avoid ever using read to parse a non-haskell formatted input string.
show :: Key is arguably still show abuse, but displaying Keys as filenames
is just too useful to give up.
|
| | |
|
| |
|
|
| |
having fix --force add its change.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Should have done this a long time ago.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the wrong format, with the UUID and description flipped.
This is my own damn fault for not making UUID a real type, and then relying
on the type checker to ensure my refactoring was correct -- which it wasn't!
I should probably add code to clean up bogus entries in the uuid.log, but
right now I want to get the fix out there to prevent people experiencing
this bug.
I should also make UUID a real data type.
|
| | |
|
| |
|
|
|
| |
The last commit added some git-log calls to a merge. This removes some,
by only merging branches that have unique refs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
Joey Hess
gernot
Valentin_Haenel