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
