git lock files (Was: GIT for Microsoft Access projects)

[Stefan Beller <sbeller@google.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]  [--] <path/to/file>
    git lock remove [branch] [--] <path/to/file>
    git lock ls [<branch>]

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 <path/to/file>
            return -1
        else
            echo $(git config --get user.name) $(date) > <path/to/file>
            git add <path/to/file> && git commit "add new lock"
        fi
    case remove:
        if exist <path/to/file>
            # todo: check if the same user locked it before
            rm  <path/to/file>
        else
            return -1
        fi
    case ls:
        ls -R .
    }
    git push $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch)
    git <restore working tree, branch>

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