#musicbrainz

from time to time, I'll work on stuff and merge it into master, so you'll want stuff in there, so here's what you do:

`git checkout master`, then `git pull upstream` - this should not create a merge of any sort, merely update your work

then, go back to your branch - `git checkout start-work-on-x` and then bring it up to date with the latest work in master, `git rebase master`

so I'd be essentially forking myself, then switching back to your main?

this doesn't cause any merges at all, but has all the benefits of branching :)

brianfreud: yes, but the key bit is that you're rebasing, not merging, to stay up to date

rebase is like picking up your work from the first commit, then moving it up to the latest commit on master

now there is one snag - you can't make your work public while you do this, because rebasing destroys and recreates commits

ie, files from checkout X are still changed, but I'm not re-commiting them in a difference checkout

brianfreud: basically, if I make 3 commits, that cause 3 conflicts, then you'll have to fix the conflicts on a commit by commit (so you fix the conflict exactly where it happened)

which, imo is pretty friggin sweet :P

sounds exactly like what I've been doing...

sure, but you've been using pull, which causes a merge

aCiD2: except you need to resolve them every time you rebase

luks: no you don't

once you rebase, you're at master, that won't change

if I add more conflicts, sure, they'll need to be fixed, but that's the same for a merge

brianfreud: the argument for rebase and merging isn't the most key, the most key is making your changes isolated into branches. Think of a branch (in git) as being the work done on a ticket in track

(in fact, when I work from trac, that's exactly what I do - branch for every ticket I work on)

ok, so I go to work on "thingX", git checkout -b "thingX"

yup

now I finished working on thingX, I want to work on thingY, git checkout -b "thingY"

how would I switch back to working on thingX again?

and if, while you work on thingX, you decide to work on unrelated thingY, you would `git checkout -b thingY master`

important that you branch from master, by default you'd branch from thingX, and have a branch of a branch :)

brianfreud: `git checkout thingX`

git checkout moves between branches, with -b it just means 'create a new branch and then move to it'

so I should have, minimally, an i18n branch and a js branch, then be branching out from those 2?

hmm, you wouldn't branch off those 2 - but you should have those branches as separate

why wouldn't I be branching, say, "GC" from "JS" from master?

contextual example - you want to work on guess case, git checkout -b guess-case master

because there's not really any point

the JS branch would just have loads of subbranches - so you might as well remove the indirection

I'm not going to say it.

FauxFaux: what?

Nothing at all.

brianfreud: i was hoping it wouldn't be /that/ big

well, we did essentially rewrite every single template...

I know

ah damn, I forgot to revert one file

install.TT ?

no, statistics.pm

that removes all the functionality that rob moved into news.pm

back in 10, gotta do some washing up