Re: renaming remote branches

[Jeff King <peff@peff.net>]

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

> > 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