Felipe Contreras <felipe.contre...@gmail.com> writes: > She told Git that her local svn-branch was the basis for svn-next. She > DIT NOT TELL Git to fetch from there. She told Git to fetch from any > location Git thought best to fetch from, either a) or b) would fetch > from the wrong location, but a) would be wronger, you just don't want > to admit it.
"(a) is more wrong" is just your opinion, and you are simply wrong. She is working on svn-ext based on her local git-svn the latter of which has some changes of her own on top of Eric's tree. When working on _any_ branch that bases its work on something else, you have @{u} available, but that @{u} will not stay up-to-date if you forked from work that is done outside your repository. That is what an unqualified "git fetch" is designed to help when run on a branch that bases its work on something else. If you happen to know that yoru current branch is forked from git-svn that is a local branch, then running "git fetch" becomes unnecessary for the purpose of updating @{u} (it already and always is up to date), so doing no object transfer and no ref update is absolutely the right thing to do. That is what "remote = ." gives you. In addition, that does not break the "pull = fetch + merge" equivalence you seem to be ignoring. If she wants to check what Eric has been doing, she can do "git fetch git-svn", giving the remote name she calls Eric's tree with. At that point, she is not saying "I want to check what is happening to the upstream of my _current_ branch" (and the fetched result is not something she can immediately use while on her current branch). On the other hand, an unqualified "git fetch" that slurps from my tree, which is your (b), is just plain wrong. My tree is not even related to what she is working on. Of course, when she is interested in what have been happening in my tree, she can say "git fetch origin". -- 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