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

v7

Browse source 
Install new git hooks in this version.

This does beg the question of what to do if git later gets eg a
post-smudge hook, that could run git-annex smudge --update. I think the
thing to do in that case would be to make git-annex smudge --update
install the new hooks. That way, as the user uses git-annex, the hook
would be created pretty quickly and without needing any extra syscalls
except for when git-annex smudge --update is called.

I considered doing something like that for installation of the
post-checkout and post-merge hooks, which would have avoided the need
for v7. But the only place it was cheap to do it would be in git-annex smudge
which could cheaply notice that smudge.log didn't exist yet and so know
the hooks needed to be installed. But since smudge used to populate pointer
files, it would be quite surprising if a single git checkout/merge failed
to update the work tree, and so that idea didn't work out.

The other reason for v7 is psychological -- users don't need to worry
about whether they might be running an old version of git-annex that
doesn't support their v7 repository very well. And bug reports about
"v6" have gotten a bit of a bad association in my head since they often
hit one of the known limitations and didn't realize it was experimental.

newtyped RepoVersion Int to avoid needing 2 comparisons in
versionSupportsUnlockedPointers etc. Also it's just nicer.

This commit was sponsored by John Pellman on Patreon.
This commit is contained in:
Joey Hess 2018-10-25 17:23:53 -04:00
parent 6ceeb4bae7
commit 234842a347
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
18 changed files with 160 additions and 108 deletions
Download patch file Download diff file Expand all files Collapse all files

6
doc/tips/hiding_missing_files.mdwn
View file

@ -8,10 +8,10 @@ but it needs some different workflows of using git-annex.
## getting started
To get started, your repository needs to be upgraded to v6, since the
To get started, your repository needs to be upgraded to v7, since the
feature does not work in v5 repositories.
git annex upgrade --version=6
git annex upgrade --version=7
The [[git-annex adjust|git-annex-adjust]] command sets up an adjusted form
of a git branch, in this case we'll ask it to hide missing files.
@ -124,7 +124,7 @@ I set up the repository like this:
git clone server:/path/to/podcasts
cd podcasts
git annex upgrade --version=6
git annex upgrade --version=7
git annex adjust --hide-missing
git annex group here client
git annex wanted here standard

19
doc/tips/unlocked_files.mdwn
View file

@ -15,7 +15,7 @@ by running `git annex unlock`.
# git annex unlock some_file
# echo "new content" > some_file
Back before git-annex version 6, and its v6 repository mode, unlocking a file
Back before git-annex version 7, and its v7 repository mode, unlocking a file
like this was a transient thing. You'd modify it and then `git annex add` the
modified version to the annex, and finally `git commit`. The new version of
the file was then back to being locked.
@ -29,31 +29,28 @@ to edit files repeatedly, without manually having to unlock them every time.
The [[direct_mode]] made all files be unlocked all the time, but it
had many problems of its own.
## enter v6 mode
## enter v7 mode
/!\ This is a new feature; see its [[todo_list|todo/smudge]]
for known issues.
This led to the v6 repository mode, which makes unlocked files remain
This led to the v7 repository mode, which makes unlocked files remain
unlocked after they're committed, so you can keep changing them and
committing the changes whenever you'd like. It also lets you use more
normal git commands (or even interfaces on top of git) for handling
annexed files.
To get a repository into v6 mode, you can [[upgrade|upgrades]] it.
To get a repository into v7 mode, you can [[upgrade|upgrades]] it.
This will eventually happen automatically, but for now it's a manual process
(be sure to read [[upgrades]] before doing this):
# git annex upgrade
Or, you can init a new repository in v6 mode.
Or, you can init a new repository in v7 mode.
# git init
# git annex init --version=6
# git annex init --version=7
## using it
Using a v6 repository is easy! Simply use regular git commands to add
Using a v7 repository is easy! Simply use regular git commands to add
and commit files. In a git-annex repository, git will use git-annex
to store the file contents, and the files will be left unlocked.
@ -97,7 +94,7 @@ mode is used. To make them always use unlocked mode, run:
## mixing locked and unlocked files
A v6 repository can contain both locked and unlocked files. You can switch
A v7 repository can contain both locked and unlocked files. You can switch
a file back and forth using the `git annex lock` and `git annex unlock`
commands. This changes what's stored in git between a git-annex symlink
(locked) and a git-annex pointer file (unlocked). To add a file to