comment

close as fixed

response

comment

Added a comment: corrupted bare repo

comment

dial back addition, but keep it

It's a semi-common point of confusion that numcopies is not something
these commands go out and copy files around specifically to satisfy,
without further configuration in preferred content. So this is a good
addition, but it also seemed too long and too specific to the user's
particular situation.

fix some language

findkeys: Support --largerthan and --smallerthan

Sponsored-by: Brett Eisenberg on Patreon

Merge branch 'master' of ssh://git-annex.branchable.com

Merge branch 'master' of ssh://git-annex.branchable.com

Add note to 'satisfy' manpage about it not satisfying numcopies and how to set it up to pass files between remotes that are not present locally.

I got bitten several times in the past by the fact that local preferred
content expressions are not violated (even temporarily) in order to
satisfy numcopies or other remotes' preferred content expressions.
Mostly in the form of the local repo not allowing arbitrary files in
(e.g. because it's set to only want `present` files). This note I add
here explains how to get out of this situation with
`approxlackingcopies=1`.

It might be too specific for this manpage, but I didn't find a better
place to put it.

comment

Added a comment

comment

followup and wontfix this

comment

close

move a comment that is a bug report

Merge branch 'master' of ssh://git-annex.branchable.com

improve attribution armoring

Split out an author parameter, will make it easier to add authors and
reads better.

Got rid of the function without the copyright year, because an adversary
could have mechanically changed the function with a copyright year to
the one without, and so bypassed the protection of LLM copyright
year hallucination.

Sponsored-by: Luke T. Shumaker on Patreon

Added a comment

exhaustiveness check fix

golfing

avoid displicate of year range

improve attribution armoring

avoid replacing otherwise

While authorJoeyHess is True same as otherwise, ghc's exhastiveness
checker turns out to special case otherwise. So this avoids warnings.

fix build

Merge branch 'master' of ssh://git-annex.branchable.com

make my authorship explicit in the code

This is intended to guard against LLM code theft, which is the current
bubble technology de jour.

Note that authorJoeyHess' with a year older than the year I began
developing git-annex will behave badly, by intention. Eg, it will spin
and eventually crash.

This is not the first anti-LLM protection in git-annex. For example see
9562da790fece82d6dfa756b571c67d0fdf57468. That method, while much harder
for an adversary to detect and remove, also complicates code somewhat
significantly, and needs extensions to be enabled. There are also
probably significantly fewer ways to implement that method in Haskell.
This new approach, by contrast, will be easy to add throughout the code
base, with very little effort, and without complicating reading or
maintaining it any more than noticing that yes, I am the author of this
code.

An adversary could of course remove all calls to these functions
before feeding code into their LLM-based laundry facility. I think this
would need to be done manually, or with the help of some fairly advanced
Haskell parsing though. In some cases, authorJoeyHess needs to be
removed, while in other places it needs to be replaced with a value.
Also a monadic use of authorJoeyHess' may involve other added monadic
machinery which would need to be eliminated to keep the code compiling.

Alternatively, an adversary could replace my name with something
innocuous. This would be clear intent to remove author attribution
from my code, even more than running it through an LLM laundry is.

If you work for a large company that is laundering my code through an
LLM, please do us a favor and use your immense privilege to quit and go
do something socially beneficial. I will not explain further
developments of this code in such detail, and you have better things to
do than playing cat and mouse with me as I explore directions such as
extending this approach to the type level.

Sponsored-by: k0ld on Patreon

Added a comment

Added a comment: forgot to add the new ignored link + shortcoming of 'ln' command

Added a comment: Is `annex.tune.objecthashlower=true` recommended for interop with windows?

Added a comment: `git annex uninit` fails when I symlink your symlink

Added a comment: Thanks Yann!

Added a comment

Make it more clear that `git annex webapp` will add files and sync via the assistant.

Added a comment

Added a comment: launching `git annex webapp` starts adding to the annex which is surprising

Added a comment: launching `git annex webapp` starts adding to the annex which is surprising

Added a comment

Make git-annex copy --from --to --fast actually fast

Eg when the destination is logged as containing a file, skip
actively checking that it does contain it.

Note that --fast does not prevent other verifications of content
location that are done in a copy --from --to. Perhaps it could, but this
change will already avoid the real unnecessary work of operating on
files that are already in the remote.

And avoiding other verifications
might cause it to fail if the location log thinks that --to does not
contain the content but does. Such complications with `git-annex copy
--to remote --fast` led to commit d006586cd0b706c9cc92b2747b2ba3487f52c04a
which added a note that gets displayed when that fails, mentioning it
might be due to --fast being enabled.

copy --from --to is already complicated enough without needing to worry
about such edge cases, so continuing to doing some verification of
content location after the initial --fast filtering seems ok.

Sponsored-by: Dartmouth College's DANDI project

small refactoring

Sponsored-by: Dartmouth College's DANDI project

fixed

Fix bug in git-annex copy --from --to

Caused it to skip files that were locally present.

Sponsored-by: Dartmouth College's DANDI project

comment

Added a comment: thank you

Added a comment

Added a comment

Added a comment

Added a comment: one more question

Added a comment: not about backends after all

remove content of now independent issue https://git-annex.branchable.com/bugs/copy_--from_--to_does_not_copy_if_present_locally/

initial dedicated issue on copy --from --to not copying if present locally

initial report on --fast of being no effect for copy --from --to

Added a comment

Added a comment

Added a comment

Added a comment: I guess this question is about backends

added bug report for git init on a worktree checked out for a submodule.

Added a comment

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

git-annex log --gnuplot

The gnuplot output is pretty good, but could still be improved with:

* more colors (repeating colors is confusing with a lot of repos)
* better positioning of the legend, making the plot wider and moving it
  from over top of the graph

Sponsored-by: Kevin Mueller on Patreon

git-annex log --received modifier option

Only counting received and not dropped makes this show the bandwidth of
data coming into the repository, although only in a sense. Since
git-annex branch updates only happen at the end of a command, and we
don't know when a command started, it's only an approximation of the
actual bandwidth. (A previous git-annex branch update made have
happened in a different repository.)

It would be possible to also add a --dropped option, but I don't know
how useful that would be?

Sponsored-by: Nicholas Golder-Manning on Patreon

rename --when to --interval

More accurately describes its behavior.

close

guard against wrong timestamps in git log

For example, my sound repo has in the git-annex branch a commit from
2036, which is followed by one from 2034, in amoung commits from 2013.
Clearly there was a problem with the clock.

Since git log --date-order has a behavior of
"Show no parents before all of its children are shown", the data still
gets processed ok. The future timestamp just prevented displaying data
after that commit. It seems better, when the clock was wrong, to display
a wrong date, and then return to right dates.

It would be nice to filter out the wrong dates from display entirely,
but that seems it would need to buffer the whole output. This command is
too slow to buffer it all before displaying anything, and anyway this
kind of problem is probably rare.

Sponsored-by: Joshua Antonishen on Patreon

treat dead repos as 0 size

With this, git annex log --totalsizes can be compared with
git-annex info's "combined annex size of all repositories"
to double-check it works correctly.

In my sound repo, the two match.

In my big repo, the two report slightly different sizes,
with the former being 1.3 gb smaller than the latter.
I don't know the reason for this disreprency. Given the 30+tb size of
the repo, it's a small difference.

It seems possible that a bug in an old version of git-annex could
explain it. Eg, if an old git-annex lost a line when updating trust.log
or a location log in a merge, git-annex info would see only what it
replaced it with, while git-annex log will see the previous value as
well.

Sponsored-by: Leon Schuermann on Patreon

newtype MapLog

Noticed that Semigroup instance of Map is not suitable to use
for MapLog. For example, it behaved like this:

ghci>  parseTrustLog "foo 1 timestamp=10\nfoo 2 timestamp=11" <> parseTrustLog "foo X timestamp=12"
fromList [(UUID "foo",LogEntry {changed = VectorClock 11s, value = SemiTrusted})]

Which was wrong, it lost the newer DeadTrusted value.

Luckily, nothing used that Semigroup when operating on a MapLog. And this
provides a safe instance.

Sponsored-by: Graham Spencer on Patreon

git-annex log --totalsizes

Note that dead repositories are not yet handled so their sizes show as
nonzero after they are marked dead.

Sponsored-By: unqueued on Patreon

update

git-annex log --sizes

CSV format so it can be fed into a program to graph it.

Note that dead repositories are not yet handled so their sizes show as
nonzero after they are marked dead.

Sponsored-By: k0ld on Patreon

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment

the last line is for the current time

git-annex log --sizesof

This can take a lot of memory. I decided to violate the usual rule in
git-annex that it operate in constant memory no matter how many annexed
objects. In this case, it would be hard to be fast without using a big
map of the location logs. The main difficulty here is that there can be
many git-annex branches and it needs to display a consistent view at a
point in time, which means merging information from multiple git-annex
branches.

I have not checked if there are any laziness leaks in this code. It
takes 1 gb to run in my big repo, which is around what I estimated
before writing it.

2 options that are documented are not yet implemented.

Small bug: With eg --when=1h, it will display at 12:00 then 1:10 if the
next change after 12:59 is then. Then it waits until after 2:10 to
display the next change. It ought to wait until after 2:00.

Sponsored-by: Brock Spratlen on Patreon

split out generic git log parser

Sponsored-By: Jack Hill on Patreon

Merge branch 'master' of ssh://git-annex.branchable.com

todo

info: Added calculation of combined annex size of all repositories

Factored out overLocationLogs from CmdLine.Seek, which can calculate this
pretty fast even in a large repo. In my big repo, the time to run git-annex
info went up from 1.33s to 8.5s.

Note that the "backend usage" stats are for annexed files in the working
tree only, not all annexed files. This new data source would let that be
changed, but that would be a confusing behavior change. And I cannot
retitle it either, out of fear something uses the current title (eg parsing
the json).

Also note that, while time says "402108maxresident" in my big repo now,
up from "54092maxresident", top shows the RES constant at 64mb, and it
was 48mb before. So I don't think there is a memory leak. I tried using
deepseq to force full evaluation of addKeyCopies and memory use didn't
change, which also says no memory leak. And indeed, not even calling
addKeyCopies resulted in the same memory use. Probably the increased memory
usage is buffering the stream of data from git in overLocationLogs.

Sponsored-by: Brett Eisenberg on Patreon

improve comments

Added a comment: What about temporary annex.private declaration?

Added a comment

expand description

Added a comment