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

Re: building git ; need suggestion

From
David Aguilar <davvid@gmail.com>
Date
Mar 19, 2013, 02:11 UTC
Message-ID
<CAJDDKr6bmH6gDSBPN+U6LbSNrFw-adsfv0ZESDAOG7H2nuZapg@mail.gmail.com>
In-Reply-To
<9E0367AC-617A-440B-925E-5796CF2E1ADF@infoservices.in>

On Mon, Mar 18, 2013 at 5:24 AM, Joydeep Bakshi <joydeep.bakshi@infoservices.in> wrote:

> 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

You should try gitolite. It has very flexible rules, and it's already been implemented for you ;-)

https://github.com/sitaramc/gitolite
Show 61 quoted lines
> ===========================
> #!/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:
>
>>
>> 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
>
> --
> 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
-- 
David
Previous: Joydeep BakshiNext: Paul Campbell
Message 8 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.