master and origin

master and origin

[Paolo Ciarrocchi]

Hi all,
I went trough the docs I found on the web but I still don't fully
understand why if I clone a remote repository my local copy has two
branches, origin (that is always a exact copy of the remote
repository) and master which is... what? The branch supposed to be
used for local development?

I'm used to just checkout to a new branch, do my own development and
then diff against origin so I'm missing why I see the master branch.

I'm sure I'm missing something very fundamental but I cannot figure
out what is it :-)

Thanks!

regards,
-- 
Paolo

Re: master and origin

[Jakub Narebski]

Paolo Ciarrocchi wrote:

> I went trough the docs I found on the web but I still don't fully
> understand why if I clone a remote repository my local copy has two
> branches, origin (that is always a exact copy of the remote
> repository) and master which is... what? The branch supposed to be
> used for local development?
> 
> I'm used to just checkout to a new branch, do my own development and
> then diff against origin so I'm missing why I see the master branch.
> 
> I'm sure I'm missing something very fundamental but I cannot figure
> out what is it :-)

Nothing very fundamental. The 'master' branch is (as name indicates)
default branch on which you do your own development. The 'origin' branch
is used to track 'master' branch in the repository you cloned from.
If you don't do your development on 'master', but use other branches,
the 'master'/'origin' is unnecessary; you could fetch 'master' into
'master'...

By the way, if you clone with --use-separate-remote you would get
separate namespace for tracking branches; additionally they would
be treated read-only (can't commit to).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: master and origin

[Jakub Narebski]

Paolo Ciarrocchi wrote:
> On 10/29/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Paolo Ciarrocchi wrote:
>>
>>> I went trough the docs I found on the web but I still don't fully
>>> understand why if I clone a remote repository my local copy has two
>>> branches, origin (that is always a exact copy of the remote
>>> repository) and master which is... what? The branch supposed to be
>>> used for local development?
>>>
>>> I'm used to just checkout to a new branch, do my own development and
>>> then diff against origin so I'm missing why I see the master branch.
[...]
>> If you don't do your development on 'master', but use other branches,
>> the 'master'/'origin' is unnecessary; you could fetch 'master' into
>> 'master'...
>>
>> By the way, if you clone with --use-separate-remote you would get
>> separate namespace for tracking branches; additionally they would
>> be treated read-only (can't commit to).
> 
> There is still one thing I don't understand, if I pull the git or
> kernel repository all the local branches are updated according to the
> remote branches, right? If I'm hacking on master what will happen to
> my local changes?

With the default setup (git clone without --use-separate-remote), then
all local branches are updated according to remote branches... with the
exception of remote 'master' branch which updates local 'origin' branch.
pull = fetch + merge, so if you pull when you are on your local 'master'
branch (and 'master' branch is first in the .git/remotes/origin file I think)
you would fetch remote 'master' into local 'origin' and merge what you
have in 'origin' into your 'master' (or merge remote 'master' into
your local 'master' if you want to think like that).

If you have uncommitted changes git would probably refuse the merge.
If you made changes to one of the tracking branches (e.g. 'next' or
'origin'), git would refuse to fetch into this branch (unless forced).

HTH
-- 
Jakub Narebski

Re: master and origin

[Paolo Ciarrocchi]

On 10/29/06, Jakub Narebski <jnareb@gmail.com> wrote:
> > There is still one thing I don't understand, if I pull the git or
> > kernel repository all the local branches are updated according to the
> > remote branches, right? If I'm hacking on master what will happen to
> > my local changes?
>
> With the default setup (git clone without --use-separate-remote), then
> all local branches are updated according to remote branches... with the
> exception of remote 'master' branch which updates local 'origin' branch.

OK, I see.

> pull = fetch + merge, so if you pull when you are on your local 'master'
> branch (and 'master' branch is first in the .git/remotes/origin file I think)
> you would fetch remote 'master' into local 'origin' and merge what you
> have in 'origin' into your 'master' (or merge remote 'master' into
> your local 'master' if you want to think like that).

So in this case, there is a difference between doing my local
development under master or myownlocalbranch. Right?
I mean, if I do my own development under master and I pull, the master
branch will include origin and my local changes. Corret?
While if I work in my local branch the datas are not modified with a
pull, because pull will update only the local copy of the remote
branch. Correct?

> If you have uncommitted changes git would probably refuse the merge.
> If you made changes to one of the tracking branches (e.g. 'next' or
> 'origin'), git would refuse to fetch into this branch (unless forced).
>
> HTH

It does, a lot!

Ciao,
-- 
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8

Non credo nelle otto del mattino. Però esistono. Le otto del mattino
sono l'incontrovertibile prova della presenza del male nel mondo.

Re: master and origin

[Jakub Narebski]

Paolo Ciarrocchi wrote:
> On 10/29/06, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
>> pull = fetch + merge, so if you pull when you are on your local 'master'
>> branch (and 'master' branch is first in the .git/remotes/origin file I think)
>> you would fetch remote 'master' into local 'origin' and merge what you
>> have in 'origin' into your 'master' (or merge remote 'master' into
>> your local 'master' if you want to think like that).
> 
> So in this case, there is a difference between doing my local
> development under master or myownlocalbranch. Right?
> I mean, if I do my own development under master and I pull, the master
> branch will include origin and my local changes. Corret?
> While if I work in my local branch the datas are not modified with a
> pull, because pull will update only the local copy of the remote
> branch. Correct?

To be more exact (sorry for the confusion) "git pull" means first do
the "git fetch", i.e. update local 'tracking' branches with the contents
of remote branches. For ordinary clone this means:

    remote (origin)  | local
   ------------------+------------------
    master           | origin
    next             | next
    ...              | ...

For --use-separate-remote this means

   remote (origin)   | local
  -------------------+-------------------
   master            | refs/remotes/origin/master
   next              | refs/remotes/origin/next
   ...               | ...

Then it does "merge". It takes the remote branch from first Pull: line in
remotes/origin file, or first in remote.origin.fetch configuration variable,
and merges it with _current_ branch.

So if you always work on local branches, and newer want to merge
automatically, you probably should use "git fetch" for fetching changes.


What is not obvious (and is PITA for first-timers) that to merge
some <sidebranch> into your <branch>, it is simplest to first switch
to <branch> using
  git checkout <branch>
and then merge <sidebranch> using
  git pull . <sidebranch>
(where '.' means local repository).

HTH
-- 
Jakub Narebski

Re: master and origin

[Luben Tuikov]

--- Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> 
> So in this case, there is a difference between doing my local
> development under master or myownlocalbranch. Right?
> I mean, if I do my own development under master and I pull, the master
> branch will include origin and my local changes. Corret?
> While if I work in my local branch the datas are not modified with a
> pull, because pull will update only the local copy of the remote
> branch. Correct?

Following GIT's working flow isn't that much different than
other SCM's workflow.

Leave master and origin branches alone.  Imagine they are your
local copy of that imaginary "root" repo.

If you want to do development, create your own branch off of
master at some point, say HEAD, using git-branch, call it my-branch.

Then do your development in my-branch, occasionally pulling from
master, all the while you update master on a regular basis
from the remote repo.  That pull into my-branch would schedule
the merge for you and if it cannot auto-merge, it will leave it
up to you do _resolve_ and then commit.  Eventually
you get into the habit of following the same commands in the
same steps.

Note the key words here: pull, merge, commit.  Pull and merge is
is done by git-pull, and if there's things to resolve you do that
manually, in most simplistic ways.

If you're coming from another SCM, picking up git is a snap.
I think the only "hurdle" coming from another SCM especially
centralized is the decentralized nature of git.

Reading git-fetch, git-pull documentation very carefully
should clear things up.

     Luben

Re: master and origin

[Luben Tuikov]

--- Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> Hi all,
> I went trough the docs I found on the web but I still don't fully
> understand why if I clone a remote repository my local copy has two
> branches, origin (that is always a exact copy of the remote
> repository) and master which is... what? The branch supposed to be
> used for local development?
> 
> I'm used to just checkout to a new branch, do my own development and
> then diff against origin so I'm missing why I see the master branch.
> 
> I'm sure I'm missing something very fundamental but I cannot figure
> out what is it :-)

Read the documentation of git-fetch and especially the second
"Note" therein.

   Luben