<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Pat,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'>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:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>OK, I had to do a bit of searching to get a copy of the script – but yes. I think this is what I need. A pretty good compromise and the steps you describe are fine. I can commit to a specific branch without trashing the workdir. Very nice. (for the VTK submodule, I just created a separate vtkwork copy of that on its own, since I only need it for the checkout/stash/apply sequence, I’m not worried about the absolute path to it).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks very much, this is really going to help.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ll lay off the Octo-Merges, functionally they’re the same as pulling kitware/master into my work branch, the topics are reasonably well separated, so merging and rerere are not yet causing me trouble.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>cheers<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>JB<span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><br><br>cd $workbranch<br>... make a bug fix on your working branch, changes uncommitted ...<br>git stash<br><br>cd $topicX<br>git stash apply<br>git commit -a -m "bug fix on topic x"<br><br>cd $workbranch<br>git merge topicx<br><br>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.<br><br><br>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:<br><br>git checkout -b development<br>git checkout -b topic-a<br>git checkout -b topic-b<br><br>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.<br><br>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!<br><br>Pat<br><br><o:p></o:p></p><div><p class=MsoNormal>On Fri, Feb 11, 2011 at 6:04 AM, Biddiscombe, John A. <<a href="mailto:biddisco@cscs.ch">biddisco@cscs.ch</a>> wrote:<o:p></o:p></p><p class=MsoNormal>David,<br><br>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').<br><br>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...<br><br>If there are better ways than two trees and two builds, I'd like to know.<br><br>JB<br>PS. you must be working all night in order to reply so fast.<o:p></o:p></p><div><div><p class=MsoNormal><br>-----Original Message-----<br>From: Thompson, David C [mailto:<a href="mailto:dcthomp@sandia.gov">dcthomp@sandia.gov</a>]<br>Sent: 11 February 2011 10:36<br>To: Biddiscombe, John A.; <a href="mailto:paraview-developers@paraview.org">paraview-developers@paraview.org</a><br>Subject: RE: Branchmaster OctoPapa and the irrresistable urge to merge<br><br>Hi John,<br><br>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.<br><br> David<br>________________________________________<br>From: <a href="mailto:paraview-developers-bounces@paraview.org">paraview-developers-bounces@paraview.org</a> [<a href="mailto:paraview-developers-bounces@paraview.org">paraview-developers-bounces@paraview.org</a>] On Behalf Of Biddiscombe, John A. [<a href="mailto:biddisco@cscs.ch">biddisco@cscs.ch</a>]<br>Sent: Friday, February 11, 2011 00:28<br>To: <a href="mailto:paraview-developers@paraview.org">paraview-developers@paraview.org</a><br>Subject: [Paraview-developers] Branchmaster OctoPapa and the irrresistable urge to merge<br><br>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.<br><br>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.<br><br>Now I discover a bug or add some new tweak and I need to commit the fix to branch X: the problem comes here<br>I am in working branch, which is based off kitware/master<br>git checkout topic X<br>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<br>commit fix to branch X<br>git checkout jbworking<br><br>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.<br><br>It seems I can process in one of two ways<br>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.<br>pro : everything up to date, so switching branches should minimize rebuilds<br>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.<br><br>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.<br>pro : Sensible way to approach things and keeps it fairly simple<br>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.<br><br>Anyway, the internet is too big and I can't read all the blogs about branch management. All of them say to do<br>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).<br><br>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].<br><br>(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)<br><br>Yours<br><br>JB<br><br><br>--<br>John Biddiscombe, email:biddisco @ <a href="http://cscs.ch" target="_blank">cscs.ch</a><br><a href="http://www.cscs.ch/" target="_blank">http://www.cscs.ch/</a><br>CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07<br>Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82<br><br>_______________________________________________<br>Paraview-developers mailing list<br><a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br><a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br><br><br>_______________________________________________<br>Paraview-developers mailing list<br><a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br><a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>