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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html