Re: disallowing push to currently checked-out branch

From: Jeff King <peff@peff.net>
Date: Feb 16, 2009, 04:01 UTC
Message-ID: <20090216040144.GB12689@coredump.intra.peff.net>
In-Reply-To: <alpine.DEB.1.10.0902151738450.14911@asgard.lang.hm>

On Sun, Feb 15, 2009 at 05:47:37PM -0800, david@lang.hm wrote:

> as I think about this more I'm puzzled as to why this is an issue.

For background, see:

  http://thread.gmane.org/gmane.comp.version-control.git/100339

  http://thread.gmane.org/gmane.comp.version-control.git/107758

  http://article.gmane.org/gmane.comp.version-control.git/108918

> in both cases the new commits are added to the repository and the commit  
> pointed to by the branch changes, but if you do the fetch your HEAD and  
> the contents of the workdir and index aren't touched, why should a push do 
> something different?

The short answer to your confusion is that fetch stores the updates in "remote tracking refs" (in refs/remotes/) but push pushes directly into the refs/heads/ hierarchy.

Note that you could set up an alternate push refspec in your client that pushes into refs/remotes/. But then people fetching from it would have to know to fetch from their instead of the regular refs/heads/ portion.

> I believe that if you fetch into a repository and someone else fetches  
> from you, they will get the content that's newer that what's in your dirty 
> workdir/index (I haven't tried it, but my understanding of the git  
> internals lead me to expect this to be the behavior)

No, they won't. Because when you fetch, your "refs/heads/master" branch (for example) is not updated. Your "refs/remotes/origin/master" branch is.

Show 5 quoted lines

> If there is some reason for the normal push to try and update the HEAD,  
> index, and workdir. instead of refusing the push, how about having it put  
> the commits in the repository and then fail to change the HEAD, index, and 
> workdir if any of them contain changes? (along with a warning that it's  
> doing so).

The question is where would it "put" the commits if not in the branch you asked for, which is the one pointed to by "HEAD"?

> this should be safe to do because it will only flag on the particular  
> combination of events that will cause data loss rather than the broader  
> prohibition of "don't push if there is a workdir" that affects legitimate  
> uses as well

It's not "don't push if there is a workdir". It's "don't push into the ref that is pointed to by HEAD". Which is the exact situation that causes problems.

-Peff