Re: master and origin

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 Ciarrocchi wrote:

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).

--- Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:

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

   Luben

Paolo Ciarrocchi wrote:

[...]

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

On 10/29/06, Jakub Narebski <jnareb@gmail.com> wrote:

OK, I see.

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?

It does, a lot!

Ciao,

Paolo Ciarrocchi wrote:

[...]

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

--- Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:

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