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

> 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;

> (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

> > 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.