Re: receive.denyCurrentBranch

[Jay Soffian <jaysoffian@gmail.com>]

On Mon, Feb 9, 2009 at 12:06 AM, Theodore Tso <tytso@mit.edu> wrote:
> On Sun, Feb 08, 2009 at 08:47:26PM -0500, Jay Soffian wrote:
>>
>> [receive]
>>      prefix = refs/remotes/incoming
>>
>> Then a push to refs/heads/master was automatically stored as
>> refs/remotes/incoming/master instead.
>
> What happens when the next person pushes to the same remote repo, and
> their refs/heads/master push is not a fast-forward merge of the
> current refs/remotes/incoming/master?
>
> Do you lose the first user's push at that point?  Or do you refuse the
> push?

The idea initially was to give a place to store the push head for the
checked-out branch, but that isn't what HEAD points to. But it seemed
confusing to do this for just the checked-out branch, so I was playing
with having all incoming pushes go into their own namespace, hence the
prefix.

Also, the use case I have in mind here is an individual with a
workstation and a laptop, and the repository on the workstation and
its clone on the laptop are both non-bare. There are not multiple
individuals pushing to the non-bare repo. Someone please correct me if
I'm wrong, but it is my impression that these are the users that have
motivated the receive.denyCurrentBranch option (and its eventual
default changing to refuse) in the first place.

In that case, the work-flow is typically:

server$ mkdir repo && cd repo && git init
server$ ... add, commit, add, commit ...
  [...time passes...]
laptop$ git clone ssh://server/~/repo
laptop$ ... add, commit, add, commit ...
laptop$ git push
laptop$ ssh server
server$ cd repo
server$ git merge incoming/master
server$ git branch -dr incoming/master

But, to answer your question, the non-fast-forward push is rejected,
unless the user forces it, unless receive.denyNonFastForwards prevents
the force.

j.