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

Re: [PATCH 2/2] git-init: set receive.guardCurrentBranch = true for non-bare repositories

From
Daniel Barkalow <barkalow@iabervon.org>
Date
Mar 24, 2008, 22:08 UTC
Message-ID
<alpine.LNX.1.00.0803241714520.19665@iabervon.org>
In-Reply-To
<alpine.LSU.1.00.0803241807210.4353@racer.site>
On Mon, 24 Mar 2008, Johannes Schindelin wrote:
Show 67 quoted lines
> Hi,
> 
> On Mon, 24 Mar 2008, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > On Sun, 23 Mar 2008, Junio C Hamano wrote:
> > > ...
> > >> As I described in my other message, I suspect that treating the 
> > >> current branch specially like this is a wrong approach.  The 
> > >> configuration might be a good idea, but shouldn't it prevent any 
> > >> local branch from getting updated?  Push into non-bare repository is 
> > >> simply a fetch run in reverse direction.
> > >
> > > That would break this work flow:
> > >
> > > 	# machine A
> > > 	$ git push B master:refs/heads/tmp
> > >
> > > 	# machine B
> > > 	$ git merge tmp
> > > 	$ git branch -d tmp
> > 
> > I am afraid that the above is irrelevant.
> > 
> > (1) You can push the temporary into anywhere outside refs/heads/ if that
> >     becomes the problem;
> 
> Okay, didn't think about that one.
> 
> > (2) Your change to forbid current branch already "breaks" another workflow
> >     (which I happen to use everyday) anyway:
> > 
> > 	# machine A (primary development repository)
> >         $ git push k.org ;# master->master, next->next, ...
> > 
> >         # machine B (build test repository)
> >         $ git reset --hard
> >         $ for b in master maint next pu
> >           do git checkout $b && make clean test || break
> > 	  done
> 
> It would not, because it is not activated by default.  Only newly 
> initialised repositories will have that config variable set.
> 
> > > Besides, there is a _vital_ difference between the current branch,...
> > 
> > [...]
> >
> > Now think.  What if one of these operations you do in the repository to 
> > advance the tip was to merge from one of _your_ local branches?  Yes, 
> > you end up merging something you did not expect to merge if you allowed 
> > a push from sideways to affect that local branch, only because the 
> > branch happened to be un-checked-out and you implemented this protection 
> > to forbid only to current branch.  Allowing a push from sideways to any 
> > local branch destabilizes your work environment, not just the current 
> > one.
> 
> Okay, I am starting to see the light.
> 
> How about
> 
> 	receive.localBranches = (refuse | allow)
> 
> with a default "allow"?  Then we could add more rope later with the 
> "update" option, which would run "git read-tree -u -m HEAD" if the current 
> branch is updated, and simply allow all other branches being updated.

The use cases I've seen for pushing into a non-bare repository seem to be cases in which "refs/heads/" isn't really local; it's only updated by push from elsewhere, and it's named "refs/heads/" because that's where public branches are served from. This suggests we could have:

	core.noLocalBranches: true
with the implications:
 - it's definitely okay to push to refs/heads/
 - HEAD is always detached.

That seems to me to accurately describe a repository used to hold branches for public consumption and where there's a work tree for testing and building, rather than development. (I.e., work tree operations only read the repository.)

	-Daniel
*This .sig left intentionally blank*
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 7 of 11 in “Introduce receive.guardCurrentBranch”
  1. 1/2 Introduce receive.guardCurrentBranchJohannes Schindelin, Mar 23, 2008
  2. 2/2 git-init: set receive.guardCurrentBranch = true for non-bare repositoriesJohannes Schindelin, Mar 23, 2008
  3. Junio C HamanoMar 24, 2008
  4. Johannes SchindelinMar 24, 2008
  5. Junio C HamanoMar 24, 2008
  6. Johannes SchindelinMar 24, 2008
  7. Daniel BarkalowMar 24, 2008
  8. Johannes SchindelinMar 24, 2008
  9. Miklos VajnaMar 24, 2008
  10. Johannes SchindelinMar 24, 2008
  11. Miklos VajnaMar 24, 2008

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.