| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Generalized LocationLog to PresenceLog, and use a presence log to record
urls for the web special remote.
|
| |\
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | |
| |
| |
| |
| |
| | |
This is substantially slower than using make, does not build or install
documentation, does not run the test suite, and is not particularly
recommended, but could be useful to some.
|
| | |
| |
| |
| |
| |
| | |
Rebenchmarked v2 vs v3, and v3 is now actually faster. Yes, storing data
in git, using git as a filesystem is actually faster than just using the
filesystem. If you do it just right. :)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
other content.
Write files in raw mode, to avoid mangling the encoding of content
provided.
Note: This was a longstanding problem, it was not introduced in v3.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All commands that often have to read a lot of information from
the git-annex branch should now be nearly as fast as before
the branch was introduced.
Before fsck was taking approximatly 3 hours, now it's running in 8 minutes.
The code is very nasty. It should be rewritten to read the header line
from git cat-file, and then read the specified number of bytes of content.
|
| |\|
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Since the logs have just been moved into the git-annex branch, don't need
to worry about backwards compatability with old versions of git-annex that
would fail to parse location logs with extra fields tacked on.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Many more commands can work in bare repos now, thanks to the git-annex
branch.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new git subcommand, that does a generic union merge operation
between two refs, storing the result in a branch. It operates efficiently
without touching the working tree. It does need to write out a temporary
index file, and may need to write out some other temp files as well.
This could be useful for anything that stores data in a branch,
and needs to merge changes into that branch without actually checking the
branch out. Since conflict handling can't be done without a working copy,
the merge type is always a union merge, which is fine for data stored in
log format (as git-annex does), or in non-conflicting files
(as pristine-tar does).
This probably belongs in git proper, but it will live in git-annex for now.
---
Plan is to move .git-annex/ to a git-annex branch, and use git-union-merge
to handle merging changes when pulling from remotes.
Some preliminary benchmarking using real .git-annex/ data indicates
that it's quite fast, except for the "git add" call, which is as slow
as "git add" tends to be with a big index.
|
| |
|
|
| |
repositories that are not configured remotes.
|
| |
|
|
|
|
|
|
|
| |
cp is still used when copying file from repos on the same filesystem, since
--reflink=auto can make it significantly faster on filesystems such as
btrfs.
Directory special remotes still use cp, not rsync. It's not clear what
tmp file should be used when rsyncing to such a remote.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
get not honoring --from has surprised me a few times, so least surprise
suggests it should just behave like copy --from. This leaves the difference
between get and copy being that copy always requires the remote to copy
from, while get will decide whether to get a file from a key/value store or
a remote.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Avoid git reset here too, so I no longer need to care that it's much more
expensive than seems wise (but I asked the git list about that anyway).
It's not necessary to reset the staged file content from the index, as
the `git add` of the the symlink will replace it anyway.
`git commit` of unlocked files is still slow, since git still has to shove
their entire content into the index, only to have it be thrown away. So it's
still better to use `git annex add`
|
| |
|
|
|
| |
Previously, lock would skip files that had staged changes, but that is
counterintuitive, I think.
|
| |
|
|
| |
reset`, and only running `git checkout` once, even when many files are being locked.
|
| |
|
|
| |
Introduced in 43f0a666f0f6cc152a2b778921831d6d7daedcaf
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
repository instead of just "foo". Closes: #627563
|
| |
|
|
| |
pulled in by missingh, but now used directly by git-annex
|
| | |
|
| |
|
|
|
|
|
| |
This takes advantage of the debug logging done by missingh, and I added
my own debug messages for executeFile calls. There are still some other
low-level ways git-annex runs stuff that are not shown by debugging,
but this gets most of it easily.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
the filename affects the key name.
|
| | |
|
| | |
|
Joey Hess