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

Fri Feb 11 10:22:38 EST 2011

Hi John,

Have you looked at git-new-workdir?  I use it, and it works great for me.
It allows you to have multiple directories that share the same .git repo
folder.  It is a little tricker to setup with VTK submodule, but it can be
done.  So you would create new workdirs for each topic branch.  Then you
could do this:

cd $workbranch
... make a bug fix on your working branch, changes uncommitted ...
git stash

cd $topicX
git stash apply
git commit -a -m "bug fix on topic x"

cd $workbranch
git merge topicx

It's like having two local clones, but you don't have to fetch from them,
they always share the same repo information.  As soon as you make a change
in one, it is visible in the other.  If you did this, you wouldn't need
multiple build directories.  But it would still be a good idea to have
multiple build directories so that you can test the bugfix on topicx, since
you developed the bugfix in workbranch, it's possible it contains code that
won't compile in topicx.

Can I also recommend that you stop doing octopus merge?  Just think of
kitware/maser as another topic branch.  So for example, let's say you were
starting from a clean checkout of kitware/master.  You'd create these new
branches:

git checkout -b development
git checkout -b topic-a
git checkout -b topic-b

Whenever you add new commits to topic-a, topic-b, or fetch new commits from
kitware/master, merge the branch with the new commits into the development
branch.  The development branch should contain only merge commits, merges
coming from topic-a, topic-b, and kitware/master.

I also recommend you read about git rerere if you haven't already added that
tool to your arsenal.  It can really help with the merges!

Pat

On Fri, Feb 11, 2011 at 6:04 AM, Biddiscombe, John A. <biddisco at cscs.ch>wrote:

> David,
>
> OK, two clones locally is one thing I've been playing with, with judicious
> cut'n'paste activity, things are ok, but it seems like a 'suboptimal'
> solution.  (I'm not having two builds on the local machine though, instead
> I'm using the one that does the nightly builds as my 'testspace').
>
> My ideal solution would be to 'commit to topic_x', I understand that this
> isn't possible with git (as it stands), because when a merge took place it'd
> need to change the working tree index (and if the merge failed...), the
> index of the working tree would be knackered, but there must be a large % of
> cases when commit to branch X would work fine and there are no merge issues,
> so somehow git ought to be able to manage it. I wonder if this is under
> development. anyway...
>
> If there are better ways than two trees and two builds, I'd like to know.
>
> JB
> PS. you must be working all night in order to reply so fast.
>
> -----Original Message-----
> From: Thompson, David C [mailto:dcthomp at sandia.gov]
> Sent: 11 February 2011 10:36
> To: Biddiscombe, John A.; paraview-developers at paraview.org
> Subject: RE: Branchmaster OctoPapa and the irrresistable urge to merge
>
> Hi John,
>
> I'm not sure my (c) is better than your (a) or (b), but what I've found
> myself doing recently is keeping 2 clones around: one named devel and one
> named boogs (sorry for the oblique reference to bugzilla's "zarro boogs
> found"). And that means 2 build directories. But it does make life easy when
> I want to commit a fix to master without switching back and forth. I've even
> been toying with the idea of having boogs do an automatic pull and build via
> cron while I'm asleep to keep it up to date.
>
>    David
> ________________________________________
> From: paraview-developers-bounces at paraview.org [
> paraview-developers-bounces at paraview.org] On Behalf Of Biddiscombe, John
> A. [biddisco at cscs.ch]
> Sent: Friday, February 11, 2011 00:28
> To: paraview-developers at paraview.org
> Subject: [Paraview-developers] Branchmaster OctoPapa and the irrresistable
> urge to merge
>
> 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
>
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
>
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20110211/6094302d/attachment-0001.htm>