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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, 24 Mar 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.

Hmm?

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux