On Mon, Feb 16, 2009 at 5:52 PM, Jeff King <peff@xxxxxxxx> wrote: > Actually, I think it is pulling from the non-bare repo that will get > confusing. > > You are proposing to push, when pushing into a non-bare repo, into a > push refspec like refs/incoming/ (for example). But what is your fetch > refspec? > > If it fetches as usual from refs/heads/, then you have an asymmetry. > That is, if I do "git push" on one client, then "git pull" on another > won't fetch the changes. I have to wait for the non-bare repo to pull > them into its refs/heads/ hierarchy (one by one, if there are multiple > branches). > > So you can try putting refs/incoming into your fetch refspec if it is a > non-bare repo. But there are two issues there: > > - how do you know the remote is non-bare? > > - now you have to "push" in the non-bare upstream in order to make > commits available. So it no longer works to do: > > workstation$ cd repo && hack hack hack && commit commit commit > laptop$ git clone workstation:repo > > since you will silently end up with stale results. > > In some ways, this is nicely rigorous: non-bare repos become > essentially "uncontactable" remotely, and you have a de facto bare > repo in the form of refs/incoming sitting in between. But I'm not > sure it matches what most users want to do, and certainly it causes > more breakage to their workflows than receive.denyCurrentBranch. My head is playing around with two ideas now that Dscho has mentioned: receive.localBranches = (refuse | allow) http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065 And PUSH_HEAD. The idea would be for side-pushes never to update a local branch, but to be recorded in PUSH_HEAD. You'd be able to rebase/merge local branch on-top of changes in PUSH_HEAD. I'm trying to figure out what can make sense when pulling from such a repo. 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
