[Paraview-developers] Branchmaster OctoPapa and the irrresistable urge to merge

Biddiscombe, John A. biddisco at cscs.ch
Fri Feb 11 03:28:43 EST 2011


I have 5 or 6 topic branches locally and I am having a bit of trouble managing the workflow, so since you guys made me use git (which is bloody marvellous, I'm not complaining), I am asking for advice.

Whenever I update from kitware, I do an update of my main master branch (=clean kitware/master) and then do an octopus merge of the 5 topic branches into my working branch. All is fine.

Now I discover a bug or add some new tweak and I need to commit the fix to branch X: the problem comes here
I am in working branch, which is based off kitware/master
git checkout topic X
topic X is based off kitware/master, several weeks ago so when I "git checkout topic X", lots of files in my working dir get touched
commit fix to branch X
git checkout jbworking

Now when I make my project, cmake reruns, tons of files are touched and I spend large portions of my life waiting for things to rebuild when I don't need them to.

It seems I can process in one of two ways
a) Update topic branches whenever I update my kitware master, so that switching to topic X only touches those files on topic branches Y,Z,A,B,C etc, which is a small subset and rebuilds are less painful. 
pro : everything up to date, so switching branches should minimize rebuilds
con : I read that we must resist the "urge to merge", because it is bad. I'm not really sure why, so please tell me. Ideally I would rebase each topic branch when I an update from kitware/master to keep things clean, unfortunately, I push these topic branches to our local repo server so rebasing is not allowed.

b) make my fixes in the working branch and commit them to the working branch, then cherry pick them regularly to each topic branch and throw away the working branch whenever I do a kitware update.
pro : Sensible way to approach things and keeps it fairly simple
con : I carry on work most evenings on the laptop and may not be ready to cherry pick fixes to the topic branches and push them. I could pull from the desktop to the laptop, but then I have to maintain another level of synchronization between machines which I guess there's no way to avoid.

Anyway, the internet is too big and I can't read all the blogs about branch management. All of them say to do 
a) stash changes, switch branch to topic, commit fixes, switch back - but these people don't work on projects as big as paraview and if you touch vtkObject.h in one topic branch, you're really stuffed because everything gets rebuilt, so I have to go b).

Please tell me what I should do - I am erring towards b). [Until recently, I just had one huge messy branch with everything on and it was a disaster, (it was a git clone of my old personal paraview svn repo), all commits were mixed up together, now I created clean topic branches and want advice].

(I hope there is a 'c' option which simply allows me to commit a fix to branch Y when I'm still on the working branch, but I have not found this yet)

Yours

JB


-- 
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82



More information about the Paraview-developers mailing list