12

Do you know if there is a way to block committing to a local git repository? In my build environment, I'm running some git commands through it and it breaks if the user makes a commit during the build.

I would like to lock the repository while the build is in progress then unlock when the build is finished.

Thanks!

schuess
  • 1,009
  • 1
  • 10
  • 21
  • 3
    Please use terms like "commit" accurately while referring to git. Multiple users don't commit into the same repository using git. – Noufal Ibrahim Aug 12 '13 at 16:33
  • 2
    Clone the repository and do a pull before your build and then build from that repository. But trying to build from a repository that multiple people are committing into seems to indicate that you are not really using git the way it's meant to be used. – jcoder Aug 12 '13 at 16:37
  • I want to block the local user from committing (or, now that I think about it, checking out to a different commit) in their own repository. I'm not worried about pushes from external sources as that doesn't automatically change HEAD – schuess Aug 12 '13 at 16:40
  • I think what the other commenters are saying, is that you just don't. It defeats the purpose of git. You fork from the 'repository' you want to work on, then work on your fork. So you can be sure it's controlled. – hometoast Aug 12 '13 at 16:43
  • 1
    If I clone from the source repository and then disconnect my laptop from the network and run off to a cave, I can commit without you even knowing. How (or more importantly, why) would you want to "lock" me from doing that? – Noufal Ibrahim Aug 12 '13 at 17:34
  • @schuess do you mean ***pushing*** commits to a repo, not ***committing*** them? These are two very different things in Git. Commiting is only done in a ***local*** repository. Users then ***push*** commits to a ***remote*** repo. –  Aug 13 '13 at 01:03
  • He says a local repo so why can't he just create a .git/index.lock file? I think other users would get [this error](http://stackoverflow.com/questions/11838793/git-git-index-lock-file-exists). I'm not saying its a good idea, more like a "goto". Plus he would lock himself out as well which may not be the intent. – crokusek Feb 28 '17 at 20:03

3 Answers3

5

TL;DR

That is not a Git-compatible work-flow. If you want an SCM with locking, use something else with a centralized-repository model. Some SCMs that support optional locks include SVN, CVS, and RCS.

Don't Push to Non-Bare Repositories

Unless you are using a shared repository configured with core.sharedRepository enabled, you should be pushing to a bare repository and running any continuous integration or build systems off a non-bare clone. By definition, any shared repository can have the working directory modified by anyone with the necessary permissions, so you shouldn't be using a shared repository if you need to ensure a stable working directory during the lifetime of some process.

There are certainly some use cases for the shared repository model. However, yours is not one of them.

Abusing Shared Repositories with Semaphores

You could certainly design your own scripts to abuse the shared-repository model. For example, you might use semaphore files (such as those created by lockfile from the lockfile-progs package) or flock in a wrapper script that turns off write or execute permissions on your shared directory before kicking off some long-running build process. That's a lot of work for a very small pay-off, since you could get the same benefit with less work with a clone. However, it is technically feasible, so I mention it here for completeness.

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
5

Look into .git/hooks/pre-commit.sample. By manipulating this hook, you should be able to disable commit operation on remote or local git repository.

Tzunghsing David Wong
  • 1,271
  • 14
  • 10
  • A have a repo containing snapshots of prior releases that should only change when I add a new release, and a repo of the current release which changes constantly and is used by others on the team. This works a treat in preventing me from accidentally adding a change to the former when I meant to add it to the latter. – Scott C Wilson Nov 03 '22 at 10:02
1

You should clone the repository and do your work in the fork.
Forks on the local disk can use symlinks to save time and space.

Git does not have any notion of a lock.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964