2016-03-29 15:33:26 +00:00
|
|
|
# NAME
|
|
|
|
|
|
|
|
git-annex adjust - enter an adjusted branch
|
|
|
|
|
|
|
|
# SYNOPSIS
|
|
|
|
|
2020-11-13 18:32:06 +00:00
|
|
|
git annex adjust `--unlock|--lock|--fix|--hide-missing [--unlock|--lock|--fix]|--unlock-present`
|
2016-03-29 15:33:26 +00:00
|
|
|
|
|
|
|
# DESCRIPTION
|
|
|
|
|
|
|
|
Enters an adjusted form of the current branch. The annexed files will
|
|
|
|
be treated differently. For example with --unlock all annexed files will
|
|
|
|
be unlocked.
|
|
|
|
|
|
|
|
The adjusted branch will have a name like "adjusted/master(unlocked)".
|
|
|
|
Since it's a regular git branch, you can use `git checkout` to switch
|
|
|
|
back to the original branch at any time.
|
|
|
|
|
|
|
|
While in the adjusted branch, you can use git-annex and git commands as
|
|
|
|
usual. Any commits that you make will initially only be made to the
|
|
|
|
adjusted branch.
|
|
|
|
|
2018-10-18 19:32:42 +00:00
|
|
|
To propagate commits from the adjusted branch back to the original branch,
|
2016-03-29 15:33:26 +00:00
|
|
|
and to other repositories, as well as to merge in changes from other
|
2018-10-18 19:32:42 +00:00
|
|
|
repositories, run `git annex sync`.
|
|
|
|
|
2019-08-09 17:21:15 +00:00
|
|
|
When in an adjusted branch, using `git merge otherbranch` is often not
|
|
|
|
ideal, because merging a non-adjusted branch may lead to unncessary
|
|
|
|
merge conflicts, or add files in non-adjusted form. To avoid those
|
|
|
|
problems, use `git annex merge otherbranch`.
|
|
|
|
|
2018-10-18 19:32:42 +00:00
|
|
|
Re-running this command with the same options
|
|
|
|
while inside the adjusted branch will update the adjusted branch
|
2020-11-13 18:32:06 +00:00
|
|
|
as necessary (eg for `--hide-missing` and `--unlock-present`),
|
|
|
|
and will also propagate commits back to the original branch.
|
2016-03-29 15:33:26 +00:00
|
|
|
|
|
|
|
# OPTIONS
|
|
|
|
|
|
|
|
* `--unlock`
|
|
|
|
|
|
|
|
Unlock all annexed files in the adjusted branch. This allows
|
|
|
|
annexed files to be modified.
|
|
|
|
|
2019-01-01 16:23:40 +00:00
|
|
|
Normally, unlocking a file requires a copy to be made of its content,
|
|
|
|
so that its original content is preserved, while the copy can be modified.
|
|
|
|
To use less space, annex.thin can be set to true before running this
|
|
|
|
command; this makes a hard link to the content be made instead of a copy.
|
|
|
|
(When supported by the file system.) While this can save considerable
|
|
|
|
disk space, any modification made to a file will cause the old version of the
|
|
|
|
file to be lost from the local repository. So, enable annex.thin with care.
|
|
|
|
|
2019-09-27 18:23:25 +00:00
|
|
|
When in an adjusted unlocked branch, `git annex add` will add files
|
|
|
|
unlocked instead of the default behavior of adding them locked.
|
|
|
|
|
|
|
|
* `--lock`
|
|
|
|
|
|
|
|
Lock all annexed file in the adjusted branch. This may be preferred
|
|
|
|
by those who like seeing broken symlinks when the content of an
|
|
|
|
annexed file is not present.
|
|
|
|
|
|
|
|
When in an adjusted locked branch, `git annex add` will add files locked,
|
|
|
|
as usual. However, `git add` (and `git commit -a` etc) still add files
|
|
|
|
unlocked. This is because it's not possible for those git commands to
|
|
|
|
add files locked.
|
|
|
|
|
2016-05-16 21:05:42 +00:00
|
|
|
* `--fix`
|
|
|
|
|
|
|
|
Fix the symlinks to annexed files to point to the local git annex
|
|
|
|
object directory. This can be useful if a repository is checked out in an
|
|
|
|
unusual way that prevents the symlinks committed to git from pointing at
|
|
|
|
the annex objects.
|
|
|
|
|
2018-10-18 19:32:42 +00:00
|
|
|
* `--hide-missing`
|
|
|
|
|
|
|
|
Only include annexed files in the adjusted branch when their content
|
|
|
|
is present.
|
|
|
|
|
|
|
|
The adjusted branch is not immediately changed when content availability
|
|
|
|
changes, so if you `git annex drop` files, they will become broken
|
|
|
|
links in the usual way. And when files that were missing are copied into the
|
|
|
|
repository from elsewhere, they won't immediatly become visible in the
|
2018-10-19 21:51:25 +00:00
|
|
|
branch.
|
2018-10-18 19:32:42 +00:00
|
|
|
|
|
|
|
To update the adjusted branch to reflect changes to content availability,
|
|
|
|
run `git annex adjust --hide-missing` again.
|
|
|
|
|
2018-10-19 21:51:25 +00:00
|
|
|
Despite missing files being hidden, `git annex sync --content` will
|
|
|
|
still operate on them, and can be used to download missing
|
2020-11-13 17:27:03 +00:00
|
|
|
files from remotes. It also updates the adjusted branch after
|
|
|
|
transferring content.
|
2018-10-19 21:51:25 +00:00
|
|
|
|
2019-09-27 18:23:25 +00:00
|
|
|
This option can be combined with --unlock, --lock, or --fix.
|
2018-10-18 19:32:42 +00:00
|
|
|
|
2020-11-13 18:32:06 +00:00
|
|
|
* `--unlock-present`
|
2020-11-13 17:27:03 +00:00
|
|
|
|
2020-11-13 18:32:06 +00:00
|
|
|
Unlock files whose content is present, and lock files whose content is
|
|
|
|
missing. This provides the benefits of working with unlocked files,
|
2020-11-13 17:27:03 +00:00
|
|
|
but makes it easier to see when the content of a file is not missing,
|
|
|
|
since it will be a broken symlink.
|
|
|
|
|
|
|
|
The adjusted branch is not immediately changed when content availability
|
|
|
|
changes, so when you `git annex get` files, they will remain locked.
|
|
|
|
And when you `git annex drop` files, they will remain locked and so will
|
|
|
|
not be broken symlinks.
|
|
|
|
|
|
|
|
To update the adjusted branch to reflect changes to content availability,
|
2020-11-13 18:32:06 +00:00
|
|
|
run `git annex adjust --unlock-present` again. Or use `git-annex sync
|
2020-11-13 17:27:03 +00:00
|
|
|
--content`, which updates the branch after transferring content.
|
|
|
|
|
2016-03-29 15:33:26 +00:00
|
|
|
# SEE ALSO
|
|
|
|
|
|
|
|
[[git-annex]](1)
|
|
|
|
|
|
|
|
[[git-annex-unlock]](1)
|
|
|
|
|
|
|
|
[[git-annex-upgrade]](1)
|
|
|
|
|
|
|
|
[[git-annex-sync]](1)
|
|
|
|
|
|
|
|
# AUTHOR
|
|
|
|
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|