On Mon, 24 Mar 2008, Johannes Schindelin wrote:

quoted text
> 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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html