Hilco Wijbenga <hilco.wijbe...@gmail.com> writes: > I suppose I'm not entirely clear on how this two step process is > "safer". Doing "git fetch" would seem to be harmless, right? So the > problem is with "git merge" but master should always be "behind" > origin/master so that "git merge" should just FF to origin/master > which *should* be completely safe. Does that make sense? Especially > given our use of master as an integration branch? > > [Given the trouble I have with getting people to use Git properly, I > prefer things as simple as possible. :-) ]
Between the two procedures Thomas gave you, "fetch & rebase" is safer than "fetch & reset --hard", exactly because it does not have to rely on the validity of your "which should always be behind" claim. If it is behind, there won't be any difference, but if it is *not*, the user will notice and won't lose his work on 'master' (which you may argue that he shouldn't have done). "rebase" will notice it. The key for a procedure to be safe is not having to rely on the claim of users such as "my history *should* always and already be behind", and not silently lose information when these *should*s are violated for whatever reason. After all, if all these *should*s were true, the user wouldn't have been having problems in the first place and posting to the list asking for help in the first place ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
