| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
Linking the file to the tmp dir was not necessary in the clean
filter, and it caused the ctime to change, which caused git to think
the file was changed. This caused git status to get slow as it kept
re-cleaning unchanged files.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Fixes a minor fd leak, never more than 1 in normal use,
which broke the test suite when I tried to write to
a file that was still open for a previous hashing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
d1ce927d95fe7c331cbff3317797a60aa288738b put a cat-file into the fast
bloomfilter generation path. Instead, add another bloom filter which diffs
from the work tree to the index.
Also, pull the sha of the changed object out of the diffs, and cat that
object directly, rather than indirecting through the filename.
Finally, removed some hacks that are unncessary thanks to the worktree to
index diff.
|
| |
|
|
| |
The newline broke this ad-hoc parser; use the normal one.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
(but not git rmed). git still has the add staged in this case, so the content should not be unused and was wrongly treated as such.
So, we need to look at both the file on disk to see if it's a annex link,
and the file in the index too. lookupFile doesn't look in the index if the file
is not present on disk.
|
| | |
| |
| |
| | |
fix is not relevant for unlocked files
|
| | |
| |
| |
| |
| |
| |
| | |
have to change the content of unlocked file before committing
otherwise git commit will fail in v6 mode when the file was already
unlocked, because no changes have been made
|
| | |
| |
| |
| | |
file is locked here, so use right test.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
In v5, that was not possible, but it is in v6, and so the test was failing.
Investigating, it turns out that locking was copying the pointer file
content to the annex object despite the content not being present. So,
add a check to prevent that.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The repo path is typically relative, not absolute, so
providing it to absPathFrom doesn't yield an absolute path.
This is not a bug, just unclear documentation.
Indeed, there seem to be no reason to simplifyPath here, which absPathFrom
does, so instead just combine the repo path and the TopFilePath.
Also, removed an export of the TopFilePath constructor; asTopFilePath
is provided to construct one as-is.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes several bugs with updates of pointer files. When eg, running
git annex drop --from localremote
it was updating the pointer file in the local repository, not the remote.
Also, fixes drop ../foo when run in a subdir, and probably lots of other
problems. Test suite drops from ~30 to 11 failures now.
TopFilePath is used to force thinking about what the filepath is relative
to.
The data stored in the sqlite db is still just a plain string, and
TopFilePath is a newtype, so there's no overhead involved in using it in
DataBase.Keys.
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
This reverts commit 85379a479663a9ef15a66a99700eb38469b5e14a.
Wow, applied to wrong project entirely.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: Jelmer Vernooij <jelmer@jelmer.uk>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
Joey Hess
ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626
mark@6b90344cdab3158eacb94a3944460d138afc9bef
felix.hagemann@b76e9ea0928cf33dacffc37ec3dbecf33171a8a5
Yaroslav Halchenko
Jelmer Vernooij
CandyAngel
grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f
https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4
umeboshi
sameerds
eigengrau
ColinW