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

> 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
>