Hi,
i have an already existing git repository with a branch (master) and i added git annex to it (git annex init). Now i want to synchronise the file tracking information with annex through git annex sync, but keep the master branch unsynchronised (i want push/pull it manually as there are not only annexed files but also code). What is the best approach for my setup?
Sounds like you should just use normal
git push/git pullcommands. Works fine with git-annex.Just be sure to include the
git-annexbranch in your pushes. Eg,git push origin master git-annexYou'll probably want to run
git annex mergeafter pulling, to merge the local and remote git-annex branches.Thank you for your response.
So annex looks like it's not really designed to work with an existing git repository, but only standalone?!
I struggle to see how you could draw that conclusion from what I said.
git-annex will work fine in an existing git repository. You can mix regular git commands like
git add,git push,git pull,git mergewith git-annex commands likegit annex add,git annex copy --to origin,git annex get,git annex merge, in the same repository.The
git annex synccommand effcetively runsgit commit; git pull; git annex merge; git push; git annex copy --to origin; git annex get. If you don't want to run all those commands at once, you don't want to rungit annex sync. That will not prevent you from using git-annex in any way.Hi,
thank you for your response. I just want to control my branches (master, dev and so on ...) by myself, without sync/master or sync/dev and without merging it automatically. But the git-annex branch should be populated between the repositories "magically" (some kind of "git annex syncannex"). As annex can't deliver such a basic functionality i assumed, that it was not designed to work with existing "real" git repositories.
I have explained clearly in comment #1 above how to do what you want to do, using git-annex, so it is a pity if still think that "annex can't deliver such a basic functionality".
It can. I have explained how. I don't know how to explain any better.
To be more precise on how to accomplish this - say for synchronizing special remotes for repos that are otherwise completely different - one might consider:
git push destination git-annex:synced/git-annex. This is what git-annex does under the hood during thepushstep of thesync.destination, rungit annex merge. This performs the merging ofsynced/git-annexintogit-annex.I found this useful when I was trying to set up multiple repositories to use one central location (an rclone special remote) for file content sharing. Since the repos had a shared context (a project), but were otherwise disjoint from one another,
syncwas not an option. However, I felt odd runninggit annex initremotefor each repo separately because then I could end up with myriad special remotes with the same configuration but different UUIDs for each. Ultimately this is not a problem - to have the same special remote have different UUIDs in different repositories - so long as the repos never come in contact. But I, novice as I was, had already muddled the git-annex branches of these repos together already, so for sake of cleanliness I went back and reimplemented these special remotes as the same UUID on every repo. This often involved adding repos as remotes to one another, fetching - which implicitly performs some merging - and then pushing (as above) any metadata changes to the repo, leaving content changes untouched.