Forgot to add the list in my reply, sorry...

---------- Doorgestuurd bericht ----------
Van: "Lieven Hollevoet" <lieven@lika.be>
Datum: 11 jul. 2013 06:38
Onderwerp: Re: google calendar
Aan: "H Plato" <hplato@gmail.com>
Cc:

Hey Plato,

Op 11 jul. 2013 06:32 schreef "H Plato" <hplato@gmail.com> het volgende:
>
> I'm getting there, I have stable and master, and adding a few files in.

Good to hear.

>
> I looked and my copy of ical2vsdb is the same as in 3.0 (although the git lib/vsDB.pm and lib/vsLock.pm are older than what I use). What problem do you have with google calendar? I added in two mh.ini options, syncing datestamps and a darwin calendar server fix (which is also applicable to google I've found)

None, but I plan to add calendar support to MisterHouse soon so if there are open issues with it I am interested in knowing them.

>
> Here's my google calendar mh.ini settings:
>
> ical2vsdb_hp = http://www.google.com/calendar/ical/hplato%40gmail.com/private-blahblahblahblah/basic.ics
> ical2vsdb_hp_options = sync_dtstamp,dcsfix,name=Me
>
> On 2013-07-10, at 3:38 PM, H Plato <hplato@gmail.com> wrote:
>
> > Sorry, you lost me at "
> >> Then on your local machine clone your own repo. This will be default give you the stable branch"

Actually I think you found it out already but with bit it is super easy to keep multiple branches in a single working copy. Of course you probably need a clone for actually running misterhouse and one for development but switching between branches in a single clone is as easy as 'git checkout branchname'

> >
> > So i should have two local repositories? A local copy of master and a
> > separate one with my customizations? Wouldn't my local one have the
> > calserv fixes? Why would i need a third branch and local copy?
> >
> > Regarding calendar, there was a change on how the ics file is parsed.
> > Can't remember when i fixed it, i thought i uploaded it to svn. I
> > could send you the file offlist, and if it works you could add it into
> > 3.0.
> >
> > Sent from my mobile device.
> >
> > On 2013-07-10, at 3:18 PM, Lieven Hollevoet <lieven@lika.be> wrote:
> >
> >> Hey Plato,
> >>
> >> if you plan to submit code, then you better go this way (short form, more details on the wiki I linked to earlier):
> >>
> >> - create a github account
> >>
> >> - clone the hollie/misterhouse repo by pressing the 'copy' button when you navigate to hollie/misterhouse repo web page. This will create a hplato/misterhouse repo linked to your user account. You do this to ensure you have a place to commit your changes to that is available to other users (as the clone on your computer is not available for other developers to pull from).
> >>
> >> Then on your local machine clone your own repo. This will be default give you the stable branch.
> >>
> >> Checkout the master branch as this is the branch where development is taking place on and where you can create pull requests for.
> >>
> >> Create, starting from that master branch a branch where you plan to commit your local changes to (= the changes that make up your working version with your local changes, let us all this branch hplato_local for further reference).
> >>
> >> When you plan to submit the changes to google calendar, create a new branch *starting from the master branch again* that will contain that changes. Call that one calserv_fixes. If you branch off your hplato_local then the pull request will contain also your local changes, this is not what you want.
> >>
> >> Once the changes are OK, merge them to your local branch (so you have them in your branch) and create a pull request (through the web interface of github) to hollie/misterhouse to request inclusion of your changes.
> >>
> >> Compared to SVN merging branches in git is easy. E.g. to merge the claserv fixes into your local branch, just do:
> >>
> >> git checkout hplato_local
> >> git merge calserv_fixes
> >>
> >> All done!
> >>
> >> I hope this clarifies the flow a bit, and by the way: I'm very interested in the google calendar fixes, also to know what is wrong with it currently.
> >>
> >> Kind regards,
> >> Lieven.
> >>
> >> Op 10-jul.-2013, om 22:42 heeft H Plato het volgende geschreven:
> >>
> >>> Almost makes sense. So i'll have my own repository, and i'll commit
> >>> local changes when i make customizations. Similar to today with svn,
> >>> and will be pretty simple to get up and going i think.
> >>>
> >>> Now, say after this is stable, i'd want to share some of the google
> >>> calendar fixes i made. I'd then fork a branch off my local repository
> >>> and call it calserv. Then i'd push this up to github so others could
> >>> help? Would that calserv branch also have all my other customizations?
> >>>
> >>> Sent from my mobile device.
> >>>
> >>> On 2013-07-10, at 9:50 AM, Lieven Hollevoet <lieven@lika.be> wrote:
> >>>
> >>>> Hey Plato,
> >>>>
> >>>> Op 10-jul.-2013, om 16:46 heeft H Plato <hplato@gmail.com> het volgende geschreven:
> >>>>
> >>>>> Ah that makes sense. In svn, i rarely 'committed' files as most were
> >>>>> customized for my local setup and not relevant for others.
> >>>>>
> >>>>> I'm a little unclear why i'd have multiple local branches. I should be
> >>>>> able to just work out of my local repository, and commit my changes
> >>>>> when I'm ready to pull down collective updates, correct?
> >>>>
> >>>> the flow of working with git is that if you want to work on a feature or a fix, you create a new branch. When you make a branch and push it to a public repository location, it enables other users to pull this branch (containing the changes you want to apply in the 'mother repository') to their local working copy for evaluation. Also, it enables you to create so-called pull requests for easy integration of your changes into the mother branch. See https://github.com/hollie/misterhouse/pulls for examples to see how this looks like.
> >>>>
> >>>> Basically creating a branch for your changes eases validation of your changes and also enables other users to cooperate with you on those changes. This concept is a little bit different from what is regularly used in SVN, where to my experience branching is used less frequently.
> >>>>
> >>>>>
> >>>>> On 2013-07-10, at 8:27 AM, Michael Stovenour <michael@stovenour.net> wrote:
> >>>>>
> >>>>>> On July 09, 2013 11:12 PM H Plato wrote:
> >>>>>>>
> >>>>>>> I got that error when i issued the 'git pull' command after i copied
> >>>>>>> in all my changed files. This was just to test the process, so i
> >>>>>>> shouldn't have copied in files like bin/mh.
> >>>>>>
> >>>>>> Being a new Git user, you might be missing one point.  When you copy the files over; from
> >>>>>> a Git perspective you are essentially editing those files.  You then need to commit those
> >>>>>> changes to the local Git repository using "git stage -u" and "git commit".  Ideally you
> >>>>>> should not have uncommitted changes on your local file system before trying to merge (pull
> >>>>>> == fetch/merge) from another repository.
> >>>>
> >>>> Michael, good catch, that is indeed the reason.
> >>>>
> >>>> Kind regards,
> >>>> Lieven.
> >>
>