1

I've been using git as part of my daily team workflow for around 3.5 years. We have favored a mostly centralized setup where there is one "blessed" repo and at most a handful of forks, mainly for people without push access to do pull requests. As we work primarily on games, we have lots of binary assets, along with other files (usually metadata, user interface layouts, etc.) that are meant to be solely machine-edited even if they are technically plaintext.

It would benefit our team greatly if we had some sort of client tool built on top of git that would help us to coordinate changes to these kinds of files to avoid the possibility of a binary (or otherwise unresolvable) conflict. Previously we have used informal conversation to coordinate advisory locks, and now we have moved to a Google Docs spreadsheet. Since we are already using a mostly centralized workflow, I think a fairly naive advisory file locking scheme would be more effective for communication as it could enforce the lock more strongly. However, I have been unsuccessful in finding such a tool.

Here's my first crack at the feature set of this tool to give an idea of the functionality I'm looking for. If I can't find something along these lines I'm probably going to write this myself at some point, but I'd rather not reinvent the wheel.

  • Tool is either a git script (like git-annex) or some combination of local hooks (we're using github so we can't use remote ones unless they are webhooks)
  • You can request a file lock by running a command, which for target file foo creates or updates the lock file .foo.gitlock with contents such as some sort of user id (email?) and possibly an approximate end date that you think you will want the lock for. The tool might also make the target file read-only in this commit.
  • You then must commit the lock file and push/pull request it to the blessed remote (probably origin) - first push wins.
  • You now have the lock. The tool changes the target file to read-write if it was not already.
  • You may edit, commit, and push changes to the file with relative exclusivity.
  • You run a command to unlock the file when you are done. It can:
    • Stay tracked by the locking system, requiring another user to take the lock before becoming read-write to her (in order to mitigate sync issues,) or:
    • You can remove it from the locking system which deletes the lock file and restores the original target file permissions.
  • When pulling a commit that adds or updates a lock file, the tool ensures the target file is read-only if it determines that you are not the lock holder.
  • Tool will not allow you to take the lock from another user (unless you pass --force or circumvent the tool)
  • The tool can detect locks that have gone stale (past their approx. end date) but it will not unlock them in case the lock holder has unpushed work.
  • Ambiguities (such as defining which remote is blessed and which branch is the mainline) are resolved using local configuration data.

I understand that this has shortcomings due to the nature of git. For instance, the user is responsible for keeping themselves up to date with the mainline branch in order to respect files that have just been added to lock tracking. But this is doable with a disciplined workflow (such as continuous integration) and could be aided by an email notifier on the remote. In any case I see it as an improvement over our current process.

I know things like this have come up before on the git mailing list, other SO questions etc. The only thing of substance I've seen mentioned is gitolite, which is neat but unfortunately not an option for us as a matter of policy.

References:

Community
  • 1
  • 1
Eliot
  • 5,450
  • 3
  • 32
  • 30

1 Answers1

1

gitolite, which is neat but unfortunately not an option for us as a matter of policy.

If it is because of ssh access, be aware that gitolite can very well be integrated with https access as well.

As mentioned in the thread you reference in your question:

In other words, I do not think locking is inherently bad. It is only that it is useful for a subset of workflows that git provides. So I don't think that git is the right place to implement it

gitolite, since it is about managing access to a centralized repository, is a good place to handle locking.

Since you are on GitHub, that illustrate the disjoint between a centralized file locking and a distributed Version Control System:

The easiest way to see the file is locked is that if I modified any file and push while another developer has pushed on the same repo and the same branch, my push will be rejected as non-fast-foward: I would have to pull first (or pull --rebase) and merge whatever modification has been previously done (previous to my push) locally, and then push again.

You don't lock a file, you merge any concurrent modification already published (pushed) on GitHub locally, and then push.
If said modifications involve a file you were modifying, you resolve any merge conflict locally, and then push a new version on GitHub.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks. It's because we are required to use GitHub. In most cases it works well, the only thing it really lacks from my perspective is remote hook scripts. – Eliot Jan 10 '14 at 02:31
  • @Eliot but it has web hook or "post-update" hook (which can call in turn your script): https://help.github.com/articles/post-receive-hooks – VonC Jan 10 '14 at 07:06
  • I can't think of a way to implement locking using a only a post-recieve hook on the remote (which is what github webhooks are AFAIK.) I think it would have to be an update hook so that it could reject invalid pushes. Can you think of a way to do it? – Eliot Jan 11 '14 at 13:17
  • @Eliot I agree. I have edited the answer to explain how a feature like "file locking" makes poor sense in a distributed environment. – VonC Jan 11 '14 at 14:33
  • Thanks, I understand all this and have given similar lectures in the past to people just learning DVCS. However, this is a real problem for our team and I am looking for a real solution. It will not be comprehensive but it may be "good enough" if our team members agree on a workflow that will make client-side locks actually useful. At this point I'm thinking that no such solution has been implemented; I'm probably going to implement it myself when I have a chance, and post the resultant solution here as the accepted answer. – Eliot Jan 13 '14 at 21:02