Re: renaming remote branches

From: Jeff King <peff@peff.net>
Date: Apr 16, 2009, 08:18 UTC
Message-ID: <20090416081835.GA26972@coredump.intra.peff.net>
In-Reply-To: <buoab6h2fko.fsf@dhlpc061.dev.necel.com>

On Thu, Apr 16, 2009 at 05:00:39PM +0900, Miles Bader wrote:

Show 7 quoted lines

> > If you are not sharing your repo over a dumb transport (like http), then
> > the contents of .git/info/refs shouldn't matter. If you are, then you
> > should enable the post-update hook to run update-server-info after every
> > push (i.e., it is not just the deletion that is a problem, but none of
> > your pushes is being marked in .git/info/refs).
> 
> Hmmm, there's no way to update the hooks without shell access, right...?

No, not through any means shipped with git itself. There are obvious security implications to arbitrarily modifying hooks, since they are runnable code. In other words, updating hooks is a great way to _get_ shell access. :)

There is no reason to forbid enabling hooks which have been pre-approved by the site admin, but such a policy decision is outside the scope of git itself. The only mechanism git provides is the "templates" feature of init (so that a site admin can apply the same hook setup to all repos as they are created).

> [lots of stuff seems undoable without shell access, i.e., changing
> .git/descriptions; it'd be nice if there was at least some way to frob
> all this stuff ...]

In general, git takes the approach that users can edit files in .git/ directly, and for setups where they can't, it is up to the site admin to make wrappers implementing whatever policy they want. Third party tools can provide the mechanism for accomplishing that (I don't know what support something like gitosis has for enabling hooks, updating descriptions, or moving branches, though).

-Peff