From: Stefan Beller Date: Tue, 09 Jun 2015 17:19:43 GMT Subject: git lock files (Was: GIT for Microsoft Access projects) Message-ID: <1433870383-7631-1-git-send-email-sbeller@google.com> In-Reply-To: <5576F02B.4040002@gmail.com> Just because Git allows distributed workflows, doesn't mean we should only focus on being distributed IMHO. The question for content not being mergable easily pops up all the time. (Game/Graphics designers, documents, all this binary stuff, where there is no good merge driver). I could imagine a "git lock" command which looks like this: git config lock.centralServer origin git config lock.defaultBranch master git lock add [branch] [--] git lock remove [branch] [--] git lock ls [] And the way this is implemented is roughly (unoptimized, just showing how you would achieve this with todays command set): git fetch --depth=1 $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch) git checkout refs/locks/$(git config --get lock.centralServer)/$(git config --get lock.defaultBranch) switch(option) { case add: if exist return -1 else echo $(git config --get user.name) $(date) > git add && git commit "add new lock" fi case remove: if exist # todo: check if the same user locked it before rm else return -1 fi case ls: ls -R . } git push $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch) git That said you could just manipulate the git objects directly, no need to check out to the working dir. The server would only need to allow pushes to a refs/locks directory and be done. the client side would need to have a plumbing command, so you could easily integrate a git locking to your application if you don't want to provide a merge driver. Thanks, Stefan