| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
* annex.thin and annex.hardlink are now supported on Windows.
* unannex --fast now makes hard links on Windows.
|
|
|
|
|
|
| |
Rationalle: User might have hook scripts whose output they want to see.
Also, git commit output may tell the user they forgot to add a file.
The output is not too ugly when there's nothing to commit.
|
|
|
|
|
|
| |
Was using L.readFile, so the Handle would remain open until the garbage
collector got around to it. Changed to explicit open and close, so we know
it's always closed when the function returns.
|
|
|
|
|
|
|
|
| |
unlocked branch.
This makes the direct mode to v6 upgrade able to be performed in one clone
of a repository without affecting other clones, which can continue using v5
and direct mode.
|
|\ |
|
| | |
|
| |
| |
| |
| | |
Also cleaned up ugliness with zombies.
|
| |
| |
| |
| | |
a filesystem not supporting symlinks.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This does mean that it has to write out temp files containing updated
objects for the merge. So may use more disk space, and disk IO, but that
should generally win out over needing to launch N separate
git hash-object processes.
|
|
|
|
| |
Speeds up hashSymlink and hashPointerFile.
|
|
|
|
|
|
|
|
|
|
|
| |
An unlocked present file does not have a pointer file in the worktree, so
info skipped counting it.
It may be that unused was also affected by the problem, but it seemed not
to be in my tests. I think because of the use of the associatedFilesFilter.
This fix slows down both info and unused a little bit, since they have to
query the contents of files from git, but only when handling unlocked files.
|
|
|
|
| |
(cherry picked from commit 6efa2492bb0c34279f535e79228016555bdb915c)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Klaus Ethgen.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes behavior in this situation:
l1 <- lockShared Nothing "lck"
l2 <- lockShared Nothing "lck"
dropLock l1
dropLock l2
Before, the lock was dropped upon the second dropLock call, but the fd
remained open, and would never be closed while the program was running.
Fixed by a rather round-about method, but it should work well enough.
It would have been simpler to open open the shared lock once, and not open
it again in the second call to lockShared. But, that's difficult to do
atomically.
This also affects Windows and PID locks, not just posix locks.
In the case of pid locks, multiple calls to waitLock within the same
process are allowed because the side lock is locked using a posix lock,
and so multiple exclusive locks can be taken in the same process. So,
this change fixes a similar problem with pid locks.
l1 <- waitLock (Seconds 1) "lck"
l2 <- waitLock (Seconds 1) "lck"
dropLock l1
dropLock l2
Here the l2 side lock fd remained open but not locked,
although the pid lock file was removed. After this change, the second
dropLock will close both fds to the side lock, and delete the pidlock.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
been updated to also use exiftool. Thanks, Klaus Ethgen.
|
| |
| |
| |
| |
| |
| |
| | |
of numeric values.
Similarly (well, for free), support preferred content expressions like
metadata=field<number and metadata=field>number
|
| |
| |
| |
| | |
finished testing recent commits, and I did solve it
|
| | |
|
| |
| |
| |
| | |
database cannot be loaded.
|
| |
| |
| |
| | |
system gpg will be preferred over it.
|
| | |
|
| |
| |
| |
| | |
repository.
|
| |
| |
| |
| |
| |
| |
| | |
status when a large non-annexed file is present in the work tree.
The whole file was strictly read, and so buffered in memory, and remained
buffered for some time when running git-annex status.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
* add, addurl, import, importfeed: When in a v6 repository on a crippled
filesystem, add files unlocked.
* annex.addunlocked: New configuration setting, makes files always be
added unlocked. (v6 only)
|
| |
| |
| |
| |
| | |
Pointer files were not being treated as annex content, so "git annex get"
didn't replace them with the object.
|
| |
| |
| |
| | |
direct mode.
|
|/ |
|
|
|
|
|
|
| |
annex/objects but didn't reach the work tree.
This also handles fixing up after f9dfeaf801da2e4d5879b3de5895dc3cef68a329
|
|
|
|
|
| |
This also handles fixing up after the bad data written by
f9dfeaf801da2e4d5879b3de5895dc3cef68a329.
|