Hi, I'd like to know if there's an easy way to control how "git annex sync" resolves conflicts. I use git annex (with wrappers I have written) to manage repos full of debs. The debs themselves never conflict, but the metadata does. So far this works great if people check out the repo, add some debs in, regenerate the metadata from the debs (using external scripts), and then shove it back into the central repo. Many people can do this for our shared project.
This doesn't work well if two people have the repo checked out at the same time; when they "git annex sync" to shove the data back up, annex detects the merge conflict in the metadata and renames the files.
What I'd like is a flag saying that while pushing the changes upstream, the sync will only perform fast-forwards and fail if that doesn't work so my wrappers can abort the user's workflow. Any advice would be appreciated.
Failing at push seems too late; the user will already have a branch with the unwanted merge in it at that point and could have additional changes commited on top of it. And, only allowing fast-forward merges is probably not what you want either; regular non-conflicting git merges that are not fast-forwards will almost always be fine. If you did want to prevent any pushes containing non-fast-forward merges, you could do it with an
updatehook in the server's git repo.There is not currently a way to prevent
git annex syncfrom auto-resolving a merge conflict, but I think there definitely should be. Something likegit config annex.resolvemerge false. And, it probably makes sense to let that be configuration be propigated to all clones of a repository, by usinggit-annex config annex.resolvemerge falseI've implemented the annex.automerge configuration setting, for the next release. There's also a
git annex sync --no-resolvemergeIn our case (Not claiming a broader usage), failing at push is exactly what we want. We're using git-annex, with wrappers, as a transport mechanism for many-gigabyte debian repos, and in the end there's only one correct notion of what's in our repos. There's no local work that's of any significance, and we can catch problems clientside and redo as needed.
A user will log onto a small number of hosts, pulldown the repo (with scripts I wrote that wrap annex), add some debs, regenerate the apt metadata, and then commit/push all that to S3/git. And then they'll remove their checkout.
On the other side, on many repo hosts they'll get new delivered versions of the git repo, then refresh from S3, and then they're ready to serve the contents to the rest of our infra.
(I realise this is probably a weird edge case for how people use annex; we use it because it lets us use git and see who's doing things, because it works well with our centralised git repos, and because those centralised git repos are not burdened with gigantic files)
Well, a git
updatehook is the only way to utterly prevent non-ff's being pushed.Since you're checking out the repository fresh each time, your scripts could use
git annex sync --no-pull. That would fail if someone else pushed work to the repo in the meantime, and you could then use whatever git commands make sense for you to fetch and rebase on top of the new changes.