Re: working with other git branches (was: Tie Crusade - what to do now)

[Janek Warchoł]

Hi,

2013/8/18 Phil Holmes <address@hidden>:
> ----- Original Message ----- From: "Janek Warchoł"
>>
>> 2013/8/18 Thomas Morley <address@hidden>:
>>> Recently you posted
>>> http://lists.gnu.org/archive/html/lilypond-devel/2013-08/msg00138.html
>>> with the public branch
>>> dev/frax/colorful-make
>>>
>>> How do I get this branch?
>>> I.e. what to do/type?
>>
>> side-question: what git version do you have? ('git --version')
>>
>> 1) go to the directory lilypond repository (that was obvious)
>> 2) run 'git status' to see in what state is your repository.  It sould
>> say something like "on branch <branchname> [...]". If it says you have
>> uncommitted changes, you should commit or stash them before proceeding
>> (ask if you need help)
>> 3) update your repository using 'git fetch' (or 'git pull', depending
>> on your preferences), you have probably done this step recently so it
>> may not be necessary
>> 4) to go to the desired branch, run 'git checkout <branchname>' - in
>> this case, 'git checkout dev/frax/colorful-make'.  Git will probably
>> say something about seting up a branch X to track remote branch X from
>> origin.
>
>
> You'll likely generally be running in "detached head" mode if you do this -
> i.e. you've checked out a branch of the remote repository for which there is
> not a local branch on your machine.

Not quite.  That would happen if one ran
git checkout origin/dev/frax/colorful-make
(note the "origin" at the beginning).  If you simply say 'git checkout
dev/frax/colorful-make', git should make a new local branch
dev/frax/colorful-make based on the remote branch (in this case
origin/dev/frax/colorful-make).
It's quite possible that old git versions would throw some kind of
"branch doesn't exist" error instead of automating creating one -
that's why i asked Harm for his git version.

> I'm not sure if there are penalties for
> doing this, but it's worth being aware.  The major impact, I believe, is
> that if you make any changes on the branch then go back to, say, master
> ('git checkout master'), you'll lose your changes.

Well, you won't loose them - they just won't be "attached" to any
branch.  It's quite easy to recover from such situation (unless a lot
of time had passed, which may make the commit hard to find).

> What about 'git merge dev/frax/colorful-make' ?

Sounds like a bad idea to me.  This is a separate set of changes, so
it should be put in its own branch, not added to the current branch
(whatever it may be).  Unless you actually want to use the changes
from dev/frax/colorful-make *together* with some of your changes, in
which case this would be the right command.
I hope that this is clear.

BTW, there is a nice tutorial on git branches here:
http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
(the whole book is very nice in my opinion, but you probably won't
have time to read it)

cheers,
Janek