On Tue, Feb 17, 2009 at 6:43 PM, Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
