git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: building git ; need suggestion

From
JBJoydeep Bakshi <joydeep.bakshi@infoservices.in>
Date
Mar 18, 2013, 12:24 UTC
Message-ID
<9E0367AC-617A-440B-925E-5796CF2E1ADF@infoservices.in>
In-Reply-To
<C8080BF5-DC87-421D-97A1-DF5CF403A03A@infoservices.in>

I'm closer to my requirement. I have found gitweb simply provide a GUI for history check and code comparison. And the git itself is good enough to do the ACL stuff with hooks.

I already have the following code to deploy the push into its work-tree

=========================== #!/bin/bash

while read oldrev newrev ref
do
  branch=`echo $ref | cut -d/ -f3`
  if [ "master" == "$branch" ]; then
    git --work-tree=/path/under/root/dir/live-site/ checkout -f $branch
    echo 'Changes pushed live.'
  fi
  if [ "dev" == "$branch" ]; then
    git --work-tree=/path/under/root/dir/dev-site/ checkout -f $branch
    echo 'Changes pushed to dev.'
  fi
done
=========================
This code can be extended for as many branches as you have.

I now need a mechanism to restrict the user to it's own branch so that user can't push into any other branch in mistake.

Say I have

master branch -> only admin user can push here. dev branch -> only user dev1 , dev2 and master can push here. testing branch -> only user test1 and test2 can push here.

I think this can also be done with pre-receive hook. Any suggestion on the hook design is welcome. Also this can be implemented on the above hook or in a separate hook. A separate hook is better due to maintainability and then I need to call multiple pre-receive hook. Please suggest.

Thanks
On 18-Mar-2013, at 11:14 AM, Joydeep Bakshi <joydeep.bakshi@infoservices.in> wrote:
Show 15 quoted lines
> 
> On 15-Mar-2013, at 6:44 PM, Magnus Bäck <baeck@google.com> wrote:
>>> 
>> 
>> Right, but that's R/W permissions. Almost any piece of Git hosting
>> software supports restriction of pushes. Discriminating *read* access
>> between developers and maintenance people sounds like a disaster if it's
>> the same organisation. 
> 
> Just restriction on push access is what required.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous: Joydeep BakshiNext: David Aguilar
Message 7 of 10 in “building git ; need suggestion”
  1. Joydeep BakshiMar 15, 2013
  2. Joydeep BakshiMar 15, 2013
  3. Fredrik GustafssonMar 15, 2013
  4. Joydeep BakshiMar 15, 2013
  5. Magnus BäckMar 15, 2013
  6. Joydeep BakshiMar 18, 2013
  7. Joydeep BakshiMar 18, 2013
  8. David AguilarMar 19, 2013
  9. Paul CampbellMar 15, 2013
  10. Konstantin KhomoutovMar 15, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.