Version control systems

Marc Weber marco-oweber at gmx.de
Fri Aug 22 00:26:28 EDT 2008


>  Sorry for being a git n00b, but does using merge mean that we need to use 
>  in-place branch switching (which you earlier said won't work well for ghc 
>  anyways)?

You have to kind of "branches" : local ones and remote ones.
remote ones represent the state of remote ones. The only way I know of
to change them is by using git-fetch (which is called by git pull as
well) or by editing the files manually

On the other hand you normally push your local ones.

So if you have
/tmp/a/.git (heads master and mybranch)
than do cd /tmp git clone a b
git will setup
.git/refs/remotes/{master,mybranch}
.git/refs/heads/master

Now you can make mybranch local as well by
git branch mybranch remotes/mybranch
(indeed you have 4 branches, 2 tracking the remote repo and two you are
working with)

Now you can do 
git checktout master;
git merge mybranch  # merge in place within the same repo
or  
git merge remotes/mybranch  # merge with remote branch which is what you'll do when using darcs branch style
etc..

After comitting to mybrach git push will change the head of the remote
repository.

You can setup each local head branch to "track" a remote oone
automaticaly so that git pull will rebase or merge depending on your
settings (AFAIK)

So if you have an active project you end up having dozens of remote
branches but only some "heads" you are working on or you want to backup
(in case someone else rewrits history or such)

HTH
Marc Weber


More information about the Glasgow-haskell-users mailing list