git lock files (Was: GIT for Microsoft Access projects)
From: Stefan Beller <hidden>
Date: 2016-06-15 23:05:13
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