On Sat, 16 Nov 2013 16:15:49 -0800 (PST)
stoici...@aol.com wrote:

> In the documentation:
> http://git-scm.com/book/en/Git-Branching-Remote-Branches
> It mentions this:
> "you can run git fetch teamone to fetch everything the remote
> teamoneserver has that you don’t have yet. Because that server has a
> subset of the data your origin server has right now, Git fetches no
> data but sets a remote branch called teamone/master to point to the
> commit that teamone has as its master branch"
> What does it mean "subset of the data"? Let's say I have one remote 
> repository called origin and my local copy points to origin/master.
> Then I run git remote add teamone git://git.team1.ourcompany.com,
> which adds a second remote repository. So now I have a remote
> repository at origin/master and a remote repository pointing at
> teamone/master. Yet I only have one local master copy. Is that one
> local master going to be affected by the two remotes when I run
> something like git fetch origin/master or git fetch teamone/master?
> If so, then I assume that means those two remotes must be in effect
> the SAME project, because obviously you don't want your local master
> to be pieces of two totally different projects. Is this correct?

No, you did not yet grok the main concept on which Git is based.
But fear not! ;-)

In Git, any repository, including your local one you're talking about
are completely independent.  This means you can fetch from and push to
*any* repository -- a repository you communicate with is not under a
requirement to host the same "project" which is being tracked in your
local repository.  Git is only concerned with commits, trees and blobs
-- the three types of objects it tracks.  When you fetch a branch or a
tag from a repository, two Git instances communicate which set of
objects is needed to be transferred so that after fetching is
finished your local repository has all the required objects to have
access to the full history of that branch or a tag you have asked to

Now understand that naming of branches is completely arbitrary.

I might have a branch named "foo" and push in into the remote
registered locally as "quux" to create a branch "bar" *there.*
Branch names have nothing in common yet still they contain the same
data.  I can now fetch "bar" from "quux" to create a remote branch
"quux/bar" locally, and this fetching would transfer exactly 0 objects
as I already have the full history of that branch.

Conversely, a branch named "master" in a remote repository might have
nothing in common with a branch "master" in the local repository.
Yes, people *tend* to think of them as if they're the same thing, but
they are not: all repositories are independent!

So, what happens if you fetched "master" from "origin" and "master"
from "teamone"?  You have two remote branches -- origin/master and
teamone/master which are merely "bookmarks" telling you which state
these branches were in when we've last seen them.
Now you're able to use regular Git tools to inspect these branches and
compare them with your local ones.
This is what `git log` with its numerous options, `git diff` and
`gitk --all` etc do.
After understanding the relation of data kept by these branches you
might one to reconcile the history of one or more of your local
branches with these.  This is what `git merge`, `git rebase`,
`git cherry-pick` are for.

So again: it helps thinking hardly about the fact your local repository
and the repositories you communicate with are independent.  In most
workflows, they *do* have very similar history but they don't *have*

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to