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

comments

Browse source
This commit is contained in:
Joey Hess 2019-10-22 00:14:03 -04:00
parent e2ba1e09cf
commit 0bff3c1070
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 68 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

11
doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_2_8a5c445e505d503b166ca82a2cb99852._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2019-10-22T03:25:10Z"
content="""
I understand that you may have a strong dislike of that, Ilya, but I
think it's unwarranted and unhelpful to drag discussion of it into
a question like this.
(I'd say more, but this is not the place.)
"""]]

35
doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_3_04a920f5b86a203d050ee4a9a0f8a33d._comment Normal file
View file

@ -0,0 +1,35 @@
[[!comment format=mdwn
username="joey"
subject="""answering the question"""
date="2019-10-22T03:28:47Z"
content="""
In detail, this is exactly what is entailed by the upgrade process
of a repository that is not in direct mode:
* git is configured to run git-annex as a smudge/clean filter by
adding a `[filter "annex"]` section to .git/config and installing a
.git/info/attributes file to contain "filter=annex"
(or modifying it if the repo already has one).
* git-annex scans the repository for files that are currently unlocked,
and updates bookkeeping about them (including the git index),
since unlocked files are treated differently in v7. git will treat
those unlocked files as unstaged changes in the working tree,
that can be committed, if you choose to, since that's how unlocked
files work in v7.
* Two git hooks are installed (post-checkout and post-merge)
to run `git annex smudge --update`. (If you happened to
already have installed something in those hooks, it will not modify them
and will display a warning instead.)
* annex.version is set to 7
Notice that this process does not touch the work tree at all, or the annex
objects, so even if it somehow completely exploded, you cannot possibly
lose data. It is entirely reversable by undoing the git config changes I
listed.
And it does not break interoperation with other clones of the repository
that still use v5. So if you have qualms, my advice would be to make a
clone and try it out for yourself and see. You can prevent accidential
upgrade of any repos by
`git config --global annex.autoupgraderepository false`
"""]]

22
doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_4_b43fda0acca8cc9027f36f51b9489aa3._comment Normal file
View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="joey"
subject="""(and direct mode)"""
date="2019-10-22T04:02:12Z"
content="""
Just for completeness, here's what upgrading a direct mode repository to v7
entails:
* everything listed above
* annex.thin is set to true
* .git/annex/objects gets populated, since direct mode didn't populate
it and in v7 annexed objects always get stored there.
This involves hard linking annexed files in the work tree
into the objects directory. If the filesystem doesn't support
hard links, it unfortunately has to copy the files, which will
double the disk space used by the repository.
(There's a todo item discussing maybe clawing that space back,
but it seems to need changes to git to do.)
* An adjusted unlocked branch is created from the current branch,
and checked out.
Essentially the same as running `git annex adjust --unlock`
"""]]