| Commit message (Collapse) | Author | Age |
| |
|
|\ |
|
| |
| |
| |
| | |
In unstable now.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. git add file
2. git commit
3. modify file
4. git commit
5. git reset HEAD^
Before this fix, that resulted in git saying the file was modified. And
indeed, it didn't have the content it should in the just checked out ref,
because step 3 modified the object file for the old key.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
When a v6 unlocked files is removed from the work tree,
unused doesn't show it. When it gets removed from the index,
unused does show it. This is the same as a locked file.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This only adds 1 stat to each file fscked for locked files, so
added overhead is minimal.
For unlocked files it has to access the database to see if a file
is modified.
|
| |
| |
| |
| | |
This was a doozy!
|
| |
| |
| |
| |
| |
| |
| | |
If multiple files point to the same annex object, the user may want to
modify them independently, so don't use a hard link.
Also, check diskreserve when copying.
|
|\| |
|
| | |
|
| |\ |
|
| | |
| | |
| | |
| | | |
file it was sending tickled bugs in some php WebDAV server.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Note that the implementation uses replaceFile, so that the actual
replacement of the work tree file is atomic. This seems a good property to
have!
It would be possible for unlock in v6 mode to be run on files that do not
have their content present. However, that would be a behavior change from
before, and I don't see any immediate need to support it, so I didn't
implement it.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before the smudge filter added a trailing newline, but other things that
wrote formatPointer to a file did not.
also some new pointer staging code to use later
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This avoids querying the database when the content file doen't exist
(or otherwise fails the provided check). However, it does add overhead of
querying the database, and will certianly impact performance.
|
| | |
| | |
| | |
| | |
| | | |
This does mean one query of the database every time an object is sent.
May impact performance.
|
| | | |
|
|\| | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Keys database can hold multiple inode caches for a given key. One for
the annex object, and one for each pointer file, which may not be hard
linked to it.
Inode caches for a key are recorded when its content is added to the annex,
but only if it has known pointer files. This is to avoid the overhead of
maintaining the database when not needed.
When the smudge filter outputs a file's content, the inode cache is not
updated, because git's smudge interface doesn't let us write the file. So,
dropping will fall back to doing an expensive verification then. Ideally,
git's interface would be improved, and then the inode cache could be
updated then too.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Renamed the db to keys, since it is various info about a Keys.
Dropping a key will update its pointer files, as long as their content can
be verified to be unmodified. This falls back to checksum verification, but
I want it to use an InodeCache of the key, for speed. But, I have not made
anything populate that cache yet.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Will be used outside of direct mode for v6 unlocked files, and is already
used outside of direct mode when adding files to annex.
|
| | | |
|