Previous discussion which touched upon it was 7 years ago (unless I missed some) where part of the response was
I don't see the benefit to justify this work. git annex add is entirely predictable; it's very similar to git add. Which itself lacks a dry-run option.
Oh well:
$> git add --help | grep -e '-n, --dry' -A1
-n, --dry-run
Don’t actually add the file(s), just show if they exist and/or will be ignored.
and users submit requests against DataLad to be able to discover what file would go to git and which to git-annex. Also would be useful to know if to git-annex -- would it be locked or unlocked? Someone else might even want to discover what would be the annex key if it would go into annex, but so far I do not think it is within our desired use-case and it might be too lengthy to compute the key checksum etc.
As for
And like git add, you can certianly undo the effects of git annex add.
well -- unless there was a version staged already you don't want to loose etc.
done joey
That old todo was about adding --dry-run to all git-annex commands. That would be infeasible as discussed there. I'm willing to consider adding it to specific commands like
git-annex addor maybegit-annex drop.It's certianly possible to use
git-annex matchexpressionto check if a file matches an annex.largefiles or annex.addunlocked expression. But I think you're probably not looking for a machine-parseable way to do it. (It would not be appropriate for--dry-runoutput to be machine-parseable either.)While
git-annex adddoes report when it adds a file to git rather than the annex, it does not currently have any output difference at all for locked vs unlocked adds. I don't think I would want to change that either. If add does not do what the user wants WRT locked/unlocked, they can just usegit-annex lockorgit-annex unlockto get to the desired state.That does not make sense. Why would --dry-run help you avoid such a mistake? It's not going to tell you that you have a previous staged version that would be overwritten. If you're concerned about that happening, commit first.
Implemented
git-annex add --dry-run.As noted it does not let you tell if a file would be added locked or unlocked since
git-annex addoutput is the same either way.Also when JSON output is enabled,
git-annex addusually outputs the key, but with--dry-run, it does not. Generating the key would involve locking down the file, and by that point the command is making changes to the filesystem. Usegit-annex calckeyinstead.Implementation was not as simple as making CommandPerform a no-op. Some parts of CommandPerform actions needed to be run when doing a dry-run, in order for addingExistingLink to display its warning, and for showNote to display the very information that the user is interested in seeing from --dry-run.
A cleaner implementation would probably involve moving those actions out of CommandPerform, perhaps by splitting CommandPerform into two parts. Which would be a lot of work and still failure prone. That is why I don't think it's a good idea to add --dry-run to very many commands.