martin f krafft wrote: > In a team environment with a centralised repository, we have now > encountered multiple times a situation by which someone committed > new annex data with "git annex sync", but without "--content". As > a result, the central repository now knew about the existence of the > new content, but it wouldn't be until the person followed up to push > the content that the rest of the team could actually see it. > > Of course, this always happened right before the weekend, causing > clones with dangling and unresolvable symlinks, and correspondingly > unhappy collaborators… and scripts. > > After playing around with preferred and required content settings, > I still have not found a way to fix this. > > Ideally, there would be a way to tag a repository "content-required" > such that refs would not be updated (post-receive hook?) as long as > there were new dangling symlinks introduced.
Fundamentially, the only way to accomplish this is to make git refuse an incoming branch ref update unless conditions are met. So a git update hook is needed. I think that the level it would make sense to support such a thing in git-annex is some form of query like `git annex findref $gitref`. Which would more or less automatically support options like --not --in=here to find files whose content has not reached the central repository. That should be sufficient to write a hook script for local policy. Another way to deal with it, of course, is to use git-annex's location tracking to find the person who pushed without sending content, which can be used similarly to how `git blame` might be used when finding the person who broke the build.. > Consequentially, it would also mean that "sync --content" would need > to first send the content, then the commits There are at least two good reasons for sync --content's current ordering: 1. It's best to pull from remotes before sending content to them. This may update location tracking information, and change the set of content that needs to be sent to a remote. Which doesn't mean it has to push to remotes before sending content, but the longer the time between a pull and a push, the greater chance that the push will fail because new changes have been pushed. 2. It allows interrupting a sync before all the content is transferred, while still getting the important metadata in sync. If a git update hook blocked a push, `git annex sync` would proceed with sending content. It might make sense to have it remember the push failed beore and retry it again at the end. -- see shy jo
signature.asc
Description: Digital signature
