Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html