Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
56d28eebdc
3 changed files with 33 additions and 0 deletions
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="anarcat"
|
||||
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
|
||||
subject="similar topic"
|
||||
date="2025-02-14T17:51:29Z"
|
||||
content="""
|
||||
see also [[moving_annex_across_filesystems]]
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="anarcat"
|
||||
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
|
||||
subject="similar topic"
|
||||
date="2025-02-14T17:47:01Z"
|
||||
content="""
|
||||
see also [[forum/moving_annex_across_filesystems]]
|
||||
"""]]
|
|
@ -24,3 +24,20 @@ I believe that's because rm won't fail to remove files if they are readonly when
|
|||
Anyways - what's the proper way of doing this? I know I could `git clone` the repository and `git get` everything, but that would create another repository with a new UUID. That's duplication I do not want.
|
||||
|
||||
Thanks for the advice! -- [[anarcat]]
|
||||
|
||||
Update, years later... The problem with cloning is that it pollutes the history of the git repository, with all that location information duplicated for a repo that is effectively, immediately forgotten.
|
||||
|
||||
That said, it's quite nice to use git itself to move the repository, as it provides a more reliable way to do this:
|
||||
|
||||
cd /srv
|
||||
git clone ~/Photos
|
||||
cd Photos
|
||||
git annex get
|
||||
|
||||
As long as you don't `git-annex-sync`, you don't send the UUID back and I guess it's *possible* to `git-annex-reinit` to recycle the UUID, but I'm not sure it helps with the extra metadata created.
|
||||
|
||||
In some cases, however, this is actually what you want: you *are* creating a new repository, even if you're removing the old one. I've found that the actual, safest way to do those transfers is to clone, as sometimes `mv(1)` can fail halfway and then you have an inconsistent copy and you need to restart from scratch.
|
||||
|
||||
Furthermore, while it has been stated elsewhere ([[forum/best_way_to_move_a_git_annex_repo_trought_file_system]], [[forum/Relocating_annex_directory]]) that a git-annex "repository is just a collection of files in a directory", I would argue it's not *quite* true. A git-annex repository is quite peculiar: it has hidden files, readonly files and directories, and can have symbolic links. And while those might seem perfectly normal to a seasoned UNIX programmer or system administrator, they trigger a bunch of special edge cases that might confuse a lot of people (like broken links, permission denied errors when removing folders, etc).
|
||||
|
||||
The idea that git-annex is "just a normal folder" is nice in theory, but it breaks down in some edge cases, and I think it's important for people to be aware of that, especially when doing special operations like this.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue