On Thu, Jul 04, 2013 at 08:10:07PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jul 4, 2013 at 7:56 PM, Thomas Koch <tho...@koch.ro> wrote:
> > we're evaluating Git to be used in our companies Tool. But a hard 
> > requirement
> > is the possibility to set an "intend-to-edit" flag on a file (better path).
> > Notice that I did not use the word "lock"! :-)
> >
> > One easy implementation might be a special branch "XYZ-locks" that contains 
> > an
> > empty blob for every flagged file. So our tool just needs to check, whether 
> > a
> > blob exists for the path that's intended to edit, tries to push a commit 
> > that
> > touches the file and only allows editing if the push succeeds.
> In my experience everyone who thinks this is a hard requirement is
> wrong.

I completely agree with this.

Having said that, if you're looking at using Gitolite (which you should
if you're hosing your own repositories and not using some other hosting
solution), there is a "lock" command [1].  Note that this cannot stop
you committing changes to "locked" files locally but it does stop you
pushing changes to the central repository that touch locked files.

[1] http://gitolite.com/gitolite/locking.html
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to