Thread (44 messages) flat view 44 messages, 18 authors, 2016-06-15

Re: disallowing push to currently checked-out branch

From: Jeff King <hidden>
Date: 2016-06-15 22:46:12

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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help