Re: disallowing push to currently checked-out branch

On Sun, 15 Feb 2009, david@lang.hm wrote:

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

I think that you have a slightly misunderstanding of what fetch is usually 
configured to do.

I see mentions of it messing up the index and causing users to loose data, 
but how is it different to push into a repository that has a workdir (with or 
without dirty state in the workdir or in the index) and doing a fetch into 
that repository.

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?

This isn't the case.  A fetch will only update the refs that refer to 
the state of the remote repository.  It will not update any of your local refs 
(unless you have a mirror setup - in which case a fetch is just as bad as 
a push).

Say we have two repositories, and local is cloned from remote:

remote# git branch
* master
   foo

local# git branch   #what branches do we have to work on?
* master
   foo

local# git branch -r  #what branches do our remotes have?
   remote/master
   remote/foo

If we have updates on the master branch at remote, then "git fetch remote" 
on local will update "remote/master", but will not affect "master" - the 
currently checked out branch.  To update "master" we then have to either 
merge "remote/master" (pull) or rebase "master" onto the new head of 
"remote/master" (pull --rebase).

However, if we have updates on the master branch at local, then "git push 
remote master" will update "master" on the remote repository - the checked 
out branch.  At which point the user has to know what they are doing, or 
risk confusion and lost work, as any commit made on the remote branch will 
not take account of the changes made by the pushed commits unless care is 
taken to update the wordir first (and it doesn't make any difference if 
you didn't have dirty state before the push).

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)

Unless they are also pulling your remote tracking branches (which is not 
the default behaviour, and is a rather odd thing to do), then your fetch 
will not change what they get from you as they only get your local 
branches.

a pull would try to update the index, HEAD, and workdir, but I've seen many 
discussions about how push and pull are not symetrical, but push and fetch 
are (along with the moaning about bad names for the commands and the 
historical explination of how they got that way)

They are symetrical in operation, but not in destination.  Basically, the 
assumption is that when fetching the user is on that machine and will 
incorporate the updates themselves either using pull, or in a more manual 
way.  With push, the assumption is that there is no user on the remote 
machine only a lonely old server process, and that the changes should be 
immediately made available to anyone accessing the repository.

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).

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

David Lang
--
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

-- 
Julian

  ---
Q: Does Bill Gates use public domain software?
A: Yes, as all of the public has become Bill Gates' domain.