3

We're using git as our VCS for a small development team. I keep the main repository on our server as a bare git repository.

Management and people not involved with the project need to be able to see the code and documentation without knowing anything about git, so I also keep a clone on our server for browsing. To keep the clone up-to-date, I have installed a hook that updates the master branch of the clone whenever someone commits to the bare repository.

Here's the problem: some knucklehead always goes into the browsing clone and starts modifying code, which causes the master branch push operation to fail. I would like to figure out a way to either enforce a read-only policy on this one clone or figure out another way to keep it up-to-date.

mjohnson
  • 33
  • 1
  • 6

2 Answers2

4

The best way to deal with these situations is having a good talk with the knucklehead in question.

Otherwise the easiest is to simply use the permission system of the operating system so the files are readonly for everyone except the script which updates it from the bare repository.

You can also get reset --hard and git clean -f before pulling from the bare repo.

(Oops, sorry, did the script wipe out 2 weeks of work???? )

Peter Tillemans
  • 34,983
  • 11
  • 83
  • 114
  • 1
    Hmm, not bad ideas, but not quite there - when the developers push up to the repo the hook script runs under that developers userid, thus I'd have to ban all the developers from the clone. So I might be willing to use the git reset --hard, but I don't know of a way to trigger that in the clone. Right now the update is triggered by a commit in the repo, and the hook is a push command. Also, according to the error message, "Cannot do a hard reset with paths" – mjohnson Jun 22 '11 at 23:02
  • Oops, I was not aware that the developers pushed to the bare repo usign file access. I assumed ssh+keyfile or git-daemon access. If you do not want to go that route and you're on Unix/MacOSX you can add a pull script, and configure /etc/sudoers to allow that script to be run using sudo by the devs as the 'view-only'-user. The hook can call that using 'sudo /usr/local/bin/pull_new_version' – Peter Tillemans Jun 22 '11 at 23:09
  • I have some examples somewhere is interested, – Peter Tillemans Jun 22 '11 at 23:09
  • Actually you're original idea was 99% there. Here's how (feel free to comment if you think I'm doing something very wrong). I keep a branch called share to stay out of the way of master, and leave the clone on that branch. The update hook script is now: `cd /path/to/my/clone || exit unset GIT_DIR /usr/bin/git reset --hard /usr/bin/git checkout share /usr/bin/git pull ` - sorry not sure how to put in line breaks – mjohnson Jun 22 '11 at 23:39
3

Why not simply provide access through gitweb, cgit or some other HTTP based repository browsing interface?

https://git.wiki.kernel.org/index.php/Gitweb

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Well, we're a Linux command line interface kind of company, even management. It might be an option of last resort. – mjohnson Jun 22 '11 at 23:07