Re: disallowing push to currently checked-out branch

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Feb 16, 2009, 01:30 UTC
Message-ID: <alpine.LNX.2.00.0902160103090.7597@reaper.quantumfyre.co.uk>
In-Reply-To: <alpine.DEB.1.10.0902151738450.14911@asgard.lang.hm>

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.

Show 9 quoted lines

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

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