mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
git-annex/doc/git-annex-drop.mdwn

159 lines
4.2 KiB
Text
Raw Normal View History

Fix typo in heading that seems to result in git-annex-drop not showing up in `man -k` output
2023-01-22 15:25:35 +00:00
# NAME
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
wip Current status: * building again, but several commands are commented out * still need to implement global options, file matching options, etc
2015-07-09 23:03:21 +00:00
git-annex drop - remove content of files from repository
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
# SYNOPSIS
git annex drop `[path ...]`
# DESCRIPTION
Drops the content of annexed files from this repository, when
possible.
git-annex will refuse to drop content if it cannot verify it is
improve git-annex-drop man page required content docs Does --unused bypass required content checks in any meaningful sense? I documented it as such but am unsure of what required content setting would be considered to match unused content.
2019-06-26 16:22:59 +00:00
safe to do so. Usually this involves verifying that the content is stored
in some other repository.
Content that is required to be stored in the repository will not be dropped
even if enough copies exist elsewhere. See [[git-annex-required]](1).
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
improve documentation
2020-04-13 16:33:35 +00:00
With no parameters, tries to drop all annexed files in the current directory.
Paths of files or directories to drop can be specified.
man pages improvements Added some examples. Tightened up some language and removed some unncessary duplicate documentaton.
2020-05-12 13:07:45 +00:00
# EXAMPLES
# git annex drop *.jpeg
drop photo1.jpg (checking origin...) ok
drop photo2.jpg (unsafe)
Could only verify the existence of 0 out of 1 necessary copies
Rather than dropping this file, try using: git annex move
(Use --force to override this check, or adjust numcopies.)
failed
drop photo3.jpg (checking origin...) ok
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
# OPTIONS
* `--from=remote`
Rather than dropping the content of files in the local repository,
doc/*.mdwn: Various typo fixes
2015-05-30 14:54:14 +00:00
this option can specify a remote from which the files'
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
contents should be removed.
--auto is no longer a global option; only get, drop, and copy accept it. Not a behavior change unless you were passing it to a command that ignored it.
2015-03-25 21:06:14 +00:00
* `--auto`
--auto doc wording try to make more clear that --auto is not --all
2020-04-13 20:12:48 +00:00
Rather than trying to drop all specified files, drop only those that
document another behavior of --auto
2022-02-08 16:22:34 +00:00
are not preferred content of the repository, and avoid trying to drop
files when there are not enough other copies for the drop to be possible.
--auto is no longer a global option; only get, drop, and copy accept it. Not a behavior change unless you were passing it to a command that ignored it.
2015-03-25 21:06:14 +00:00
See [[git-annex-preferred-content]](1)
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
* `--force`
Use this option with care! It bypasses safety checks, and forces
git-annex to delete the content of the specified files, even from
the last repository that is storing their content. Data loss can
result from using this option.
document the -A shorthand for --all
2018-04-04 03:12:04 +00:00
* `--all` `-A`
drop: Now supports --all, --unused, and --key.
2015-05-12 17:00:06 +00:00
Rather than specifying a filename or path to drop, this option can be
used to drop all available versions of all files.
improve documentation
2020-04-13 16:33:35 +00:00
This is the default behavior when running git-annex drop in a bare
repository.
drop: Now supports --all, --unused, and --key.
2015-05-12 17:00:06 +00:00
--branch, stage 1 Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and whereis commands. This option makes git-annex operate on files that are included in a specified branch (or other treeish). The names of the files from the branch that are being operated on are not displayed yet; only the keys. Displaying the filenames will need changes to every affected command. Also, note that --branch can be specified repeatedly. This is not really documented, but seemed worth supporting, especially since we may later want the ability to operate on all branches matching a refspec. However, when operating on two branches that contain the same key, that key will be operated on twice.
2016-07-20 16:05:22 +00:00
Note that this bypasses checking the .gitattributes annex.numcopies
improve git-annex-drop man page required content docs Does --unused bypass required content checks in any meaningful sense? I documented it as such but am unsure of what required content setting would be considered to match unused content.
2019-06-26 16:22:59 +00:00
setting and required content settings.
--branch, stage 1 Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and whereis commands. This option makes git-annex operate on files that are included in a specified branch (or other treeish). The names of the files from the branch that are being operated on are not displayed yet; only the keys. Displaying the filenames will need changes to every affected command. Also, note that --branch can be specified repeatedly. This is not really documented, but seemed worth supporting, especially since we may later want the ability to operate on all branches matching a refspec. However, when operating on two branches that contain the same key, that key will be operated on twice.
2016-07-20 16:05:22 +00:00
* `--branch=ref`
Drop files in the specified branch or treeish.
Note that this bypasses checking the .gitattributes annex.numcopies
improve git-annex-drop man page required content docs Does --unused bypass required content checks in any meaningful sense? I documented it as such but am unsure of what required content setting would be considered to match unused content.
2019-06-26 16:22:59 +00:00
setting and required content settings.
--branch, stage 1 Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and whereis commands. This option makes git-annex operate on files that are included in a specified branch (or other treeish). The names of the files from the branch that are being operated on are not displayed yet; only the keys. Displaying the filenames will need changes to every affected command. Also, note that --branch can be specified repeatedly. This is not really documented, but seemed worth supporting, especially since we may later want the ability to operate on all branches matching a refspec. However, when operating on two branches that contain the same key, that key will be operated on twice.
2016-07-20 16:05:22 +00:00
drop: Now supports --all, --unused, and --key.
2015-05-12 17:00:06 +00:00
* `--unused`
Drop files found by last run of git-annex unused.
--branch, stage 1 Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and whereis commands. This option makes git-annex operate on files that are included in a specified branch (or other treeish). The names of the files from the branch that are being operated on are not displayed yet; only the keys. Displaying the filenames will need changes to every affected command. Also, note that --branch can be specified repeatedly. This is not really documented, but seemed worth supporting, especially since we may later want the ability to operate on all branches matching a refspec. However, when operating on two branches that contain the same key, that key will be operated on twice.
2016-07-20 16:05:22 +00:00
Note that this bypasses checking the .gitattributes annex.numcopies
improve git-annex-drop man page required content docs Does --unused bypass required content checks in any meaningful sense? I documented it as such but am unsure of what required content setting would be considered to match unused content.
2019-06-26 16:22:59 +00:00
setting and required content settings.
--branch, stage 1 Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and whereis commands. This option makes git-annex operate on files that are included in a specified branch (or other treeish). The names of the files from the branch that are being operated on are not displayed yet; only the keys. Displaying the filenames will need changes to every affected command. Also, note that --branch can be specified repeatedly. This is not really documented, but seemed worth supporting, especially since we may later want the ability to operate on all branches matching a refspec. However, when operating on two branches that contain the same key, that key will be operated on twice.
2016-07-20 16:05:22 +00:00
drop: Now supports --all, --unused, and --key.
2015-05-12 17:00:06 +00:00
* `--key=keyname`
Use this option to drop a specified key.
--branch, stage 1 Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and whereis commands. This option makes git-annex operate on files that are included in a specified branch (or other treeish). The names of the files from the branch that are being operated on are not displayed yet; only the keys. Displaying the filenames will need changes to every affected command. Also, note that --branch can be specified repeatedly. This is not really documented, but seemed worth supporting, especially since we may later want the ability to operate on all branches matching a refspec. However, when operating on two branches that contain the same key, that key will be operated on twice.
2016-07-20 16:05:22 +00:00
Note that this bypasses checking the .gitattributes annex.numcopies
improve git-annex-drop man page required content docs Does --unused bypass required content checks in any meaningful sense? I documented it as such but am unsure of what required content setting would be considered to match unused content.
2019-06-26 16:22:59 +00:00
setting and required content settings.
--branch, stage 1 Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and whereis commands. This option makes git-annex operate on files that are included in a specified branch (or other treeish). The names of the files from the branch that are being operated on are not displayed yet; only the keys. Displaying the filenames will need changes to every affected command. Also, note that --branch can be specified repeatedly. This is not really documented, but seemed worth supporting, especially since we may later want the ability to operate on all branches matching a refspec. However, when operating on two branches that contain the same key, that key will be operated on twice.
2016-07-20 16:05:22 +00:00
--batch-keys New --batch-keys option added to these commands: get, drop, move, copy, whereis git-annex-matching-options had to be reworded since some of its options can be used to match on keys, not only files. Sponsored-by: Luke Shumaker on Patreon
2021-08-25 18:20:33 +00:00
* matching options
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
The [[git-annex-matching-options]](1)
--batch-keys New --batch-keys option added to these commands: get, drop, move, copy, whereis git-annex-matching-options had to be reworded since some of its options can be used to match on keys, not only files. Sponsored-by: Luke Shumaker on Patreon
2021-08-25 18:20:33 +00:00
can be used to specify what to drop.
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
drop -Jn
2015-11-04 21:13:20 +00:00
* `--jobs=N` `-JN`
Runs multiple drop jobs in parallel. This is particularly useful
when git-annex has to contact remotes to check if it can drop files.
For example: `-J4`
annex.jobs=cpus etc Added the ability to run one job per CPU (core), by setting annex.jobs=cpus, or using option --jobs=cpus or -Jcpus. Built with future expansion in mind, including not defaulting matching on Concurrency so more constructors can later be added, and using "cpu" instead of "0".
2019-05-10 17:24:31 +00:00
Setting this to "cpus" will run one job per CPU core.
drop: Add --batch and --json options.
2016-07-06 15:54:46 +00:00
* `--batch`
Enables batch mode, in which lines containing names of files to drop
are read from stdin.
make --batch honor matching options When --batch is used with matching options like --in, --metadata, etc, only operate on the provided files when they match those options. Otherwise, a blank line is output in the batch protocol. Affected commands: find, add, whereis, drop, copy, move, get In the case of find, the documentation for --batch already said it honored the matching options. The docs for the rest didn't, but it makes sense to have them honor them. While this is a behavior change, why specify the matching options with --batch if you didn't want them to apply? Note that the batch output for all of the affected commands could already output a blank line in other cases, so batch users should already be prepared to deal with it. git-annex metadata didn't seem worth making support the matching options, since all it does is output metadata or set metadata, the use cases for using it in combination with the martching options seem small. Made it refuse to run when they're combined, leaving open the possibility for later support if a use case develops. This commit was sponsored by Brett Eisenberg on Patreon.
2018-08-08 16:03:30 +00:00
As each specified file is processed, the usual output is
displayed. If a file's content is not present, or it does not
match specified matching options, or it is not an annexed file,
a blank line is output in response instead.
--batch-keys New --batch-keys option added to these commands: get, drop, move, copy, whereis git-annex-matching-options had to be reworded since some of its options can be used to match on keys, not only files. Sponsored-by: Luke Shumaker on Patreon
2021-08-25 18:20:33 +00:00
* `--batch-keys`
This is like `--batch` but the lines read from stdin are parsed as keys.
Note that this bypasses checking the .gitattributes annex.numcopies
setting and required content settings.
added -z Added -z option to git-annex commands that use --batch, useful for supporting filenames containing newlines. It only controls input to --batch, the output will still be line delimited unless --json or etc is used to get some other output. While git often makes -z affect both input and output, I don't like trying them together, and making it affect output would have been a significant complication, and also git-annex output is generally not intended to be machine parsed, unless using --json or a format option. Commands that take pairs like "file key" still separate them with a space in --batch mode. All such commands take care to support filenames with spaces when parsing that, so there was no need to change it, and it would have needed significant changes to the batch machinery to separate tose with a null. To make fromkey and registerurl support -z, I had to give them a --batch option. The implicit batch mode they enter when not provided with input parameters does not support -z as that would have complicated option parsing. Seemed better to move these toward using the same --batch as everything else, though the implicit batch mode can still be used. This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
* `-z`
--batch-keys New --batch-keys option added to these commands: get, drop, move, copy, whereis git-annex-matching-options had to be reworded since some of its options can be used to match on keys, not only files. Sponsored-by: Luke Shumaker on Patreon
2021-08-25 18:20:33 +00:00
Makes the batch input be delimited by nulls
instead of the usual newlines.
added -z Added -z option to git-annex commands that use --batch, useful for supporting filenames containing newlines. It only controls input to --batch, the output will still be line delimited unless --json or etc is used to get some other output. While git often makes -z affect both input and output, I don't like trying them together, and making it affect output would have been a significant complication, and also git-annex output is generally not intended to be machine parsed, unless using --json or a format option. Commands that take pairs like "file key" still separate them with a space in --batch mode. All such commands take care to support filenames with spaces when parsing that, so there was no need to change it, and it would have needed significant changes to the batch machinery to separate tose with a null. To make fromkey and registerurl support -z, I had to give them a --batch option. The implicit batch mode they enter when not provided with input parameters does not support -z as that would have complicated option parsing. Seemed better to move these toward using the same --batch as everything else, though the implicit batch mode can still be used. This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
drop: Add --batch and --json options.
2016-07-06 15:54:46 +00:00
* `--json`
Enable JSON output. This is intended to be parsed by programs that use
--json-exceptions Added a --json-exceptions option, which makes some exceptions be output in json. The distinction is that --json-error-messages is for messages relating to a particular ActionItem, while --json-exceptions is for messages that are not, eg ones for a file that does not exist. It's unfortunate that we need two switches with such a fine distinction between them, but I'm worried about maintaining backwards compatability in the json output, to avoid breaking anything that parses it, and this was the way to make sure I didn't. toplevelWarning is generally used for the latter kind of message. And the other calls to toplevelWarning could be converted to showException. The only possible gotcha is that if toplevelWarning is ever called after starting acting on a file, it will add to the --json-error-messages of the json displayed for that file and converting to showException would be a behavior change. That seems unlikely, but I didn't convery everything to avoid needing to satisfy myself it was not a concern. Sponsored-by: Dartmouth College's Datalad project
2023-04-25 21:02:25 +00:00
git-annex. Each line of output is a JSON object corresponding to a file
being processed.
drop: Add --batch and --json options.
2016-07-06 15:54:46 +00:00
add --json-error-messages (not yet implemented) Added --json-error-messages option, which includes error messages in the json output, rather than outputting them to stderr. The actual rediretion of errors is not implemented yet, this is only the docs and option plumbing. This commit was supported by the NSF-funded DataLad project.
2018-02-19 18:28:17 +00:00
* `--json-error-messages`
--json-exceptions Added a --json-exceptions option, which makes some exceptions be output in json. The distinction is that --json-error-messages is for messages relating to a particular ActionItem, while --json-exceptions is for messages that are not, eg ones for a file that does not exist. It's unfortunate that we need two switches with such a fine distinction between them, but I'm worried about maintaining backwards compatability in the json output, to avoid breaking anything that parses it, and this was the way to make sure I didn't. toplevelWarning is generally used for the latter kind of message. And the other calls to toplevelWarning could be converted to showException. The only possible gotcha is that if toplevelWarning is ever called after starting acting on a file, it will add to the --json-error-messages of the json displayed for that file and converting to showException would be a behavior change. That seems unlikely, but I didn't convery everything to avoid needing to satisfy myself it was not a concern. Sponsored-by: Dartmouth College's Datalad project
2023-04-25 21:02:25 +00:00
Adds an "error-messages" field to the JSON that contains messages that
would normally be output to the standard error when processing a file.
* `--json-exceptions`
Output additional JSON objects for some exceptions that are not
associated with a particular file.
add --json-error-messages (not yet implemented) Added --json-error-messages option, which includes error messages in the json output, rather than outputting them to stderr. The actual rediretion of errors is not implemented yet, this is only the docs and option plumbing. This commit was supported by the NSF-funded DataLad project.
2018-02-19 18:28:17 +00:00
split out common options to its own page and mention it on each subcommand page Sometimes users would get confused because an option they were looking for was not mentioned on a subcommand's man page, and they had not noticed that the main git-annex man page had a list of common options. This change lets each subcommand mention the common options, similarly to how the matching options are handled. This commit was sponsored by Svenne Krap on Patreon.
2021-05-10 19:00:13 +00:00
* Also the [[git-annex-common-options]](1) can be used.
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
# SEE ALSO
[[git-annex]](1)
expand manpages cross-references significantly i found that most man pages only had references to the main git-annex manpage, which i stillfind pretty huge and hard to navigate through. i tried to sift through all the man pages and add cross-references between relevant pages. my general rule of thumb is that links should be both ways unless one of the pages is a more general page that would become ridiculously huge if all backlinks would be added (git-annex-preferred-content comes to mind). i have also make the links one per line as this is how it was done in the metadata pages so far. i did everything but the plumbing, utility and test commands, although some of those are linked from the other commands so cross-links were added there as well.
2015-05-29 16:12:55 +00:00
[[git-annex-get]](1)
[[git-annex-move]](1)
[[git-annex-copy]](1)
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
# AUTHOR
Joey Hess <id@joeyh.name>
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
Reference in a new issue Copy permalink