On Sun, 15 Feb 2009, david@xxxxxxx 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@xxxxxxxxxxxxxxx
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.
--
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
