Paolo Ciarrocchi wrote:
On 10/29/06, Jakub Narebski [off-list ref] wrote:
quoted
Paolo Ciarrocchi wrote:
quoted
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.
[...]
quoted
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
On 10/29/06, Jakub Narebski [off-list ref] wrote:
quoted
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.
--- 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
Paolo Ciarrocchi wrote:
On 10/29/06, Jakub Narebski [off-list ref] wrote:
[...]
quoted
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