misterhouse-users

Sorry if this is a duplicate for some, but I never saw it come back to me--or any responses; thus sending it again/
From: Timothy Spaulding
Sent: Saturday, February 23, 2013 8:47 PM
To: misterhouse-users@...
Subject: I have fixes: need a bit of hand holding
Hello All,
I am working to get onboard with the new github source management and in need of a bit hand holding: After a bit of trouble on my end, I think I for/cloned the latest master from hollie repository and now I have some changes I'd like to submit.
Two changes in different areas, but related to the same type of error in a function of Perl that has been deprecated/removed and caused MH to crash for me:
. UPBPIM.pm: line 184: Array string being passed as a parameter
. Musica.pm: line 1335: basically, the same problem
I have created a branch called mh_upb to fix the initial problem; and found myself working on the second one after the first was fixed. I think I can follow the instructions to stage and commit/pull these changes, but I have questions:
. Would the community like this in two different branches
. If so, how does one manages fixes in multiple branches?
. How do you have multiple branches and switch between them?
. How do you have multiple branches and continuously test/use the fixes/changes in different branches?

Timothy,
Sorry if no one has responded to you.
. Would the community like this in two different branches
>
Yes that would be preferable.
> . If so, how does one manages fixes in multiple branches?
>
Not sure how to answer that. The git online book is pretty spectacular:
http://git-scm.com/book
> . How do you have multiple branches and switch between them?
>
See above, but in simple terms:
git checkout branch1
git checkout branch2
> . How do you have multiple branches and continuously test/use the
> fixes/changes in different branches?
This I can sympathize with. Here is a brief summary of how I work,
hopefully this will answer some of your other questions.
The master branch in my repo is automatically tracked to Hollie's master
branch, I don't recall how I did this and it probably isn't necessary, but
there it is.
When development is not as feverish as it currently is, I would just
checkout my master branch and run that. When I find a bug, I often start
poking around trying to fix it. Once I have a solution, I run 'git diff'
which shows me all of the changes from master. I get rid of any
unnecessary debugging stuff that I may have added. Sometimes I completely
dump the work performed in a file with git checkout filename.
At this point, I have a fix, but no branch. So I run 'git stash' which
stores all of my changes. Then I create a new branch with git branch
new_branch. Then checkout that branch git checkout new_branch. And then
apply my changes with 'git stash apply'. Then I commit my changes in this
branch with 'git commit -a' and push them to my online repo 'git push
origin'
In other instances, I know that I am going to be doing a lot of work in a
specific area, and I start a branch from master first and skip the git
stash stuff.
The important thing is that you want your branches to start at master. If
your branch starts at another branch you have already created, then we have
a hard time merging your second branch into hollie/master without also
merging in your first changes.
Now, when you want to run a form of MH that includes your fixes from
multiple branches that have not yet been merged into hollie/master you can
simply create a new branch. I call mine running. I would create running
from master, then run git merge branch1 and then git merge branch2 on
running. Now you have your own custom version of MH.
Once your changes get accepted, you can switch back to master. As long as
no one forks your running branch, you are free to destroy it and start
over.
I hope this helps. I think the main feature of git is the ability to
branch easily. So branch away. Just look at my repo, I have tons of
various branches that were created solely to fix one thing.

On 03/01/2013 12:52 PM, Kevin Robert Keegan wrote:
>
> The important thing is that you want your branches to start at master. If your branch starts at another branch you have already created, then we have a hard time merging your second branch into hollie/master without also merging in your first changes.
>
Kevin,
Thanks for this great recap of your work flow. I found this very helpful. I continuously forget to always create a branch off master and I get into all kinds of trouble.
We all really appreciate all the hard work you are putting into MH. You and Michael both!
Regards,
Jim

Yes, thank you very much Kevin for this wonderful detailed explanation.
I was having some additional problems than Lieven helped me with off list--now, I think I have a branch published and good to go.
-----Original Message-----
From: Jim Duda [mailto:jim@...]
Sent: Friday, March 01, 2013 7:45 PM
To: misterhouse-users@...
Subject: Re: [mh] I have fixes: need a bit of hand holding
On 03/01/2013 12:52 PM, Kevin Robert Keegan wrote:
>
> The important thing is that you want your branches to start at master. If your branch starts at another branch you have already created, then we have a hard time merging your second branch into hollie/master without also merging in your first changes.
>
Kevin,
Thanks for this great recap of your work flow. I found this very helpful. I continuously forget to always create a branch off master and I get into all kinds of trouble.
We all really appreciate all the hard work you are putting into MH. You and Michael both!
Regards,
Jim
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365