Re: branch ahead in commits but push claims all up to date

[Irene Ros <imirene@gmail.com>]

Hi Daniel,

Thank you for the explanation, doing a git fetch actually did do the
trick although I still don't quite see the difference between
git pull origin myBranch
and
git fetch

When I push to origin myBranch it's clear that it actually pushes my
changes to our remote repository since others can then pull and get
them. So is it the case that:

git push ==> actual remote repository
while
git pull <== local copy of remote repository for this branch ?

In that case why is it that in all branches that I have, besides this
one, doing a 'git pull origin whateverBranch' actually pulls from the
remote branch and not the local copy? This case has been quite unique
given dozens of branches that we constantly switch to and from. We've
never actually used (or clearly saw the need for) git fetch until now.

Thank you so much for your insight, it's very helpful in understanding
these subtleties.

-- Irene



On Tue, Mar 24, 2009 at 11:19 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 24 Mar 2009, Irene Ros wrote:
>
>> Hi All,
>>
>> Thank you for the good advice. I may be the case I am somehow misusing
>> git... I couldn't resolve the issue and so I created a new project off
>> of the same repo. Switching to the same branch in question yielded an
>> even stranger result: In this new project, the commits were there (I
>> could see them in git log and in git log origin/myBranch) whereas in
>> the previous older project I did not... does that make sense? Our
>> origin branches are located on a central server so can't quite figure
>> out why viewing the log of the same remote branch from two different
>> projects would yield different results. Any suggestions? At this
>> point, I'm just really curious.
>
> origin/* is a copy of what git saw the last time it talked to the remote
> repository. This may be different from what the remote repository now
> contains. (Also, there are a few cases in which pushing to a remote
> repository doesn't count as talking to it; fetching with a configured
> remote always counts.) The local copies are handy for being able to
> compare the work you've done locally with what is in the remote repository
> when you don't necessarily have a network connection, don't expect
> constant updates remotely, or don't want to be distracted by remote
> changes. For example, you might have your local work, and you might want
> to compare it with what other people have done. You want to avoid having
> additional changes that other people make while you're making this
> comparison show up in the middle.
>
> Of course, when you make a new clone of the same repository, this clone
> will look at the repository when you make the clone, and will have the
> latest information (as of that time).
>
> In order to get an existing repository to see changes to a remote
> repository, use "git fetch <remote>" (you can leave off the <remote> to
> get the oone you gave to "clone", which is configured as "origin").
> Alternatively, you can use "git pull" to get the data and also merge it in
> the same command, which may or may not be a useful addition depending on
> your workflow.
>
>        -Daniel
> *This .sig left intentionally blank*
>