git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: receive.denyCurrentBranch

From
Jay Soffian <jaysoffian@gmail.com>
Date
Feb 9, 2009, 15:43 UTC
Message-ID
<76718490902090743j6f1bfdcdkdf9f64ca51c4a0af@mail.gmail.com>
In-Reply-To
<20090209050659.GA12655@mini-me.lan>
On Mon, Feb 9, 2009 at 12:06 AM, Theodore Tso <tytso@mit.edu> wrote:
Show 14 quoted lines
> 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.
Previous: Jay SoffianNext: Jakub Narebski
Message 14 of 15 in “receive.denyCurrentBranch”
  1. George SpelvinFeb 8, 2009
  2. Junio C HamanoFeb 8, 2009
  3. Johannes SchindelinFeb 8, 2009
  4. Jay SoffianFeb 8, 2009
  5. Johannes SchindelinFeb 8, 2009
  6. Jay SoffianFeb 8, 2009
  7. Jay SoffianFeb 8, 2009
  8. Johannes SchindelinFeb 8, 2009
  9. Junio C HamanoFeb 9, 2009
  10. Jay SoffianFeb 9, 2009
  11. Theodore TsoFeb 9, 2009
  12. Johannes SchindelinFeb 9, 2009
  13. Jay SoffianFeb 9, 2009
  14. Jay SoffianFeb 9, 2009
  15. Jakub NarebskiFeb 8, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.