Jeff King [off-list ref] writes:
In your situation, I would probably do:
ssh remote-host 'cd remote-dir && git branch -m OLD NEW'
but that is not always an option, depending on your setup.
Yup, don't have real ssh access.
quoted
Also, I note that the old name ("OLD") remains in .git/info/refs, both
locally and in the remote; is this a problem? I can update the local
.git/info/refs by running "git update-server-info", but I'm not sure how
to do in for the remote repo without having a login there...
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...?
[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 ...]
-Miles
--
Accordion, n. An instrument in harmony with the sentiments of an assassin.
On Thu, Apr 16, 2009 at 05:00:39PM +0900, Miles Bader wrote:
quoted
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