Re: PUSH_HEAD, was Re: FETCH_HEAD question

[Jay Soffian <jaysoffian@gmail.com>]

On Tue, Feb 17, 2009 at 6:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Having said that, there need to be clear and sane semantics defined to
> tell which push should go to PUSH_HEAD file and which should directly go
> to the underlying ref.  It is probably the easiest to explain if all
> pushes to local refs are redirected to PUSH_HEAD when the repository is
> non-bare, but it means a non-bare repository cannot be used as the central
> shared repository for everybody to meet and swap with push-pull.  We could
> only redirect push to the checked-out branch to PUSH_HEAD, but then that
> would introduce an inconsistency between checked-out branches and others
> from fetchers' point of view; pushes to some branches are observable from
> the outside while pushes to one special branch (the checked-out one) are
> not.

This is along the lines of what I was thinking. However, I have also
been thinking of an alternative. It would go something like this:

$ git init --hybrid

This would basically setup a repository that is a combination of bare
and non-bare and would act like having a pair or repositories. i.e.
Given,

$ mkdir project
$ cd project
$ git init
$ touch file && git add file && git commit -m initial
$ git clone --bare file://$(pwd) ../project-public.git
$ git remote add public ../project-public.git
$ git config branch.master.remote public
$ git config branch.master.merge refs/heads/master

I don't mean to suggest that git init --hybrid would literally create
two repositories. Rather, it would create a single repo that acts like
the above two. You'd "git push" to publish a branch and "git pull" to
integrate any pushed-in changes. refs/heads in such a repo would never
receive outside changes directly, nor would changes to refs/heads be
externally visible until published via push.

This would typically be used in the mothership/satellite scenario,
where the mothership repo is setup with --hybrid and the satellite is
just a normal clone.

But maybe this is a lot of work w/little reward.

j.