Felipe Contreras <felipe.contre...@gmail.com> writes:
> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> Felipe Contreras <felipe.contre...@gmail.com> writes:
>>>> If you come from "git pull" is "git fetch" + "git merge",
>>>> and if your current branch is integrating with your local branch,
>>> How many times do I have to say that 'git pull' is not 'git fetch' +
>>> 'git merge'?
>>> You must think everybody has 'merge.defaulttoupstream=true'.
>> I am confused. What does that have anything to do with this topic?
>> It only affects what a lazy "git merge" (without any other parameter
>> on the command line) does, doesn't it?
> And that's what we are talking about here; commands without any other
> parameter in the command like.
> So "git pull $nothing" is *not* "git fetch $nothing" + "git merge $nothing".
Of course not. But what does it change the equation?
Let's rephrase the above, then.
"git pull" with 0 or more arguments is to first
- make sure that necessary history is available in your
- prepare FETCH_HEAD to record what is to be merged
which is done by running "git fetch" with appropriate
arguments against the repository of your upstream, and then
- merge the upstream history
which is done by running "git merge" with appropriate
arguments (which in turn is formulated by reading FETCH_HEAD
that is left by the previous "git fetch" step).
So if your "upstream" happens to live in a local repository, it is
very natural to run "git fetch" against repository "." (with
appropriate arguments, like 'refs/heads/master' if you were on your
mywork branch that was forked from your 'master' branch). Running
"git fetch ." is hardly "does not make any sense whatever" from that
point of view. It is just a natural consequence that our local
repository is merely one of the repositories we could fetch/pull
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