On Tue, Feb 17, 2009 at 6:28 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: >> receive.localBranches = (refuse | allow) >> >> http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065 > > In the meantime, we have receive.denyCurrentBranch, which is much superior > to the localBranches design: it tackles the _real_ issue -- the only > reason why a current branch cannot be updated lightly is that it might > have a working directory which would be forced out-of-sync. Hmpfh. So both you and Junio have changed your mind since that thread then. Because in that thread, you propose receive.guardCurrentBranch, which was quite similar to today's receive.denyCurrentBranch. Junio then argues that treating just the checked-out branch as special, as opposed to all local branches is not the right thing to do: --- snip --- http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062 Step back a bit and think _why_ you wanted to prevent current branch tip from getting updated in the first place. There are two issues: * Why is it _current_ branch, and not _these branches_, that can be configured by the user to be protected from a push from sideways? * Why is it undesirable for the work tree and the index to go out of sync with respect to the branch tip to begin with? The latter is simpler to answer, so let's deal with it first. The reason why it is bad is because allowing a push to the current branch interferes with the work actively being done in the repository, using the work tree contents. There is a person, you, who is actively editing the work tree in order to advance the tip of the branch by making commits. If the branch tip moves without your knowing, that destabilizes your working environment. Your work tree wanted to make a new commit on top of some known state, but that state was moved underneath you. Not good. When you are using the repository for real work (i.e. advance the tips of its branches), you want a stable environment. You do not want its HEAD bobbing around outside your control, and silently detaching to cause your later commits to go to unnamed branch without your knowing is just as bad (which you already correctly objected to). --- snip --- And you end up agreeing: --- snip --- http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062 > 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) --- snip --- Then the thread died, with receive.localBranches going into TODO, but never got an implementation. Sometime later, receive.denyCurrentBranch came along, which is the original idea you proposed, Junio argued against, and then you agreed. So, I'm not sure what happened in the intervening time between the receive.localBranches proposal and the receive.denyCurrentBranch implementation that suddenly what is basically guardCurrentBranch became a good idea. But, I happen to agree with Junio's argument in gmane 77955. j. -- 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
