From: John <jo...@to...> - 2012-11-06 00:29:02
|
I was looking at the todo list here: http://misterhouse.wikispaces.com/Insteon+Redux Which of those is considered something that needs to be addressed before code is merged into master? Impression is they are mostly not critical but I thought there were functional gaps in insteon branch. John |
From: Marc M. <ma...@me...> - 2012-11-06 06:14:04
|
On Mon, Nov 05, 2012 at 06:28:53PM -0600, John wrote: > I was looking at the todo list here: > > http://misterhouse.wikispaces.com/Insteon+Redux > > Which of those is considered something that needs to be addressed before > code is merged into master? Impression is they are mostly not critical > but I thought there were functional gaps in insteon branch. If you can get sync all links and delete orphan links to work reliably and converge on a network with more than 10 items let's say, I would then say the code is good enough to push. Speaking of which, who is moderator of this list? The forced reply to that tries to prevent replying to the author+the list is starting to piss me off to be honest. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Timothy S. <spa...@ic...> - 2012-11-06 10:38:53
|
Hi Marc, I don't believe this list is moderated by anyone. I am one of the admins for the list and this isn't familiar to me. -----Original Message----- From: Marc MERLIN [mailto:ma...@me...] Sent: Tuesday, November 06, 2012 1:14 AM To: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon Branch: Todo On Mon, Nov 05, 2012 at 06:28:53PM -0600, John wrote: > I was looking at the todo list here: > > http://misterhouse.wikispaces.com/Insteon+Redux > > Which of those is considered something that needs to be addressed > before code is merged into master? Impression is they are mostly not > critical but I thought there were functional gaps in insteon branch. If you can get sync all links and delete orphan links to work reliably and converge on a network with more than 10 items let's say, I would then say the code is good enough to push. Speaking of which, who is moderator of this list? The forced reply to that tries to prevent replying to the author+the list is starting to piss me off to be honest. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Eloy P. <pe...@ch...> - 2012-11-06 06:18:18
|
Hi John, On 11/05/2012 07:28 PM, John wrote: > I was looking at the todo list here: > > http://misterhouse.wikispaces.com/Insteon+Redux > > Which of those is considered something that needs to be addressed before > code is merged into master? Impression is they are mostly not critical > but I thought there were functional gaps in insteon branch. I'd say the link management stuff is the most important part to have working well before the branch can be merged into the trunk. It's not just practical to have to do link management manually. Sorry I am not more specific but there is a lot of memory/link management items in that list! :-( Cheers, Eloy Paris.- |
From: Jim D. <ji...@du...> - 2012-11-06 15:24:45
|
> > If you can get sync all links and delete orphan links to work reliably and > converge on a network with more than 10 items let's say, I would then say > the code is good enough to push. > Is Gregg planning to finish this? Gregg, you listening? This might be something I'd be willing to take on, if Gregg isn't interested. Jim |
From: Marc M. <ma...@me...> - 2012-11-06 15:44:53
|
On Tue, Nov 06, 2012 at 03:24:22PM +0000, Jim Duda wrote: > > > > If you can get sync all links and delete orphan links to work reliably and > > converge on a network with more than 10 items let's say, I would then say > > the code is good enough to push. > > Is Gregg planning to finish this? Gregg, you listening? > This might be something I'd be willing to take on, if Gregg isn't interested. I talked to him a while ago, and the answer is most likely not. He has had family things that have been much more important and last I talked to him, he didn't sound like he was going to be able to finish working on the code. But just before that, he did work with me and added a lot of code that made the insteon branch almost finished. I do think it's pretty close. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Lieven H. <li...@li...> - 2012-11-07 08:11:31
|
Hello all, Op 7-nov.-2012, om 00:05 heeft John <jo...@to...> het volgende geschreven: > > For Todo, it makes sense that we focus on what is needed to merge > insteon branch back in to master no matter what version control system > is used. As a first step in merge preparation: as you can see here https://github.com/hollie/misterhouse/branches insteon branch is 33 commits behind master. This means there were 33 operations in the master branch that did not make it into insteon. The effect of this is that if people want to commit a change to the two branches, they need to manually apply that change to the two branches. See the mail with Jim on his changes to android_server.pl. This way of working is totally not cool/efficient and it is a problem that needs to be solved regardless of the VCS we use. The advantage of git is that we're able to see what the status of the branches is compared to each other and that we can try to merge the changes nicely. (Who knew insteon was 33 commits behind master when we were using SVN?) My first proposal for starting to bring the branches closer together again is: could somebody involved in the insteon branch test if the changes to master are OK for the insteon branch? To do this, we should bring those changes to the insteon branch. This is easily done with a command, but of course there are some merge conflicts: $ git status # On branch insteon nothing to commit (working directory clean) $ git merge master Auto-merging web/bin/items.pl CONFLICT (content): Merge conflict in web/bin/items.pl Auto-merging lib/xPL_Items.pm CONFLICT (content): Merge conflict in lib/xPL_Items.pm Auto-merging lib/Generic_Item.pm Auto-merging bin/mh.ini Auto-merging bin/mh Automatic merge failed; fix conflicts and then commit the result. If we can fix the conflicts (I have no time to look into them right now and I don't have insteon hardware to test) then we have master and insteon again in one-way sync and then if Jim want to add a feature to android_server,pl he can do this in master, commit it and to a git checkout insteon git merge master To bring his changes to the insteon branch. This is way cooler than having to change the same file in the same way in the two branches as it needs to be done now. The next step would then be of course merging insteon back into master when the code is stable enough. Kind regards, Lieven. |
From: John <jo...@to...> - 2012-11-07 12:56:20
|
On 11/07/12 02:11, Lieven Hollevoet wrote: > Hello all, > > Op 7-nov.-2012, om 00:05 heeft John <jo...@to...> het volgende geschreven: > >> >> For Todo, it makes sense that we focus on what is needed to merge >> insteon branch back in to master no matter what version control system >> is used. > > As a first step in merge preparation: as you can see here > https://github.com/hollie/misterhouse/branches > > insteon branch is 33 commits behind master. This means there were 33 operations in the master branch that did not make it into insteon. The effect of this is that if people want to commit a change to the two branches, they need to manually apply that change to the two branches. See the mail with Jim on his changes to android_server.pl. This way of working is totally not cool/efficient and it is a problem that needs to be solved regardless of the VCS we use. The advantage of git is that we're able to see what the status of the branches is compared to each other and that we can try to merge the changes nicely. (Who knew insteon was 33 commits behind master when we were using SVN?) Thanks for pointing this out. In addition to the extra effort needed to commit changes, it would probably also be the case that those using insteon branch aren't testing with a version that reflects how things will be when we merge the insteon changes back into master. Sorry if this is obvious but I have been a manager type for a long time now. > My first proposal for starting to bring the branches closer together again is: could somebody involved in the insteon branch test if the changes to master are OK for the insteon branch? I can spend some time doing this. Probably makes sense to have those that are working on this commit changes often so we don't duplicate our work. Also, thanks for providing the workflow steps. John |
From: Marc M. <ma...@me...> - 2012-11-07 14:35:15
|
On Wed, Nov 07, 2012 at 09:11:17AM +0100, Lieven Hollevoet wrote: > My first proposal for starting to bring the branches closer together again is: could somebody involved in the insteon branch test if the changes to master are OK for the insteon branch? I don't mind, after they've been merged, even if I don't use all the hardware that's in mh. I did a manual merge with svn a long time ago, so thanks for doing this one. > The next step would then be of course merging insteon back into master when the code is stable enough. So, all of us have been a bit worried about doing this, because the insteon branch isn't technically finished, but at the same time many of us are running the insteon branch now. At the same time, the master branch's insteon code isn't stellar either in other ways. Considering that we have svn left behind now, I actually think that it would be ok to collapse the two branches and make the new insteon code the master code. If it somehow breaks someone, they're not dead in the water because they can still fall back to the old code in svn, report the problem, and hopefully someone can help fix this in the new code. So while I can't call myself the backup insteon maintainer, I think it's time to fold both branches at least in git since the possible problems this might cause are likely far outweighed by the cost of those 2 branches. There is also the problem if all that insteon documentation I wrote that uses the old syntax. If someone feels inspired to update it with the new syntax, you have my blessing as long as for now we only update the syntax to use. After that if you want to further improve the insteon wiki, that can be done separately. If there are no volunteers, I'll see if I can make some time to do it. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Eloy P. <pe...@ch...> - 2012-11-07 21:01:44
|
On 11/07/2012 09:35 AM, Marc MERLIN wrote: [...] > Considering that we have svn left behind now, I actually think that it > would be ok to collapse the two branches and make the new insteon code the > master code. I would agree with this. > If it somehow breaks someone, they're not dead in the water because they can > still fall back to the old code in svn, report the problem, and hopefully > someone can help fix this in the new code. > > So while I can't call myself the backup insteon maintainer, I think it's > time to fold both branches at least in git since the possible problems > this might cause are likely far outweighed by the cost of those 2 branches. Yes. Also, exposing the INSTEON stack in the insteon branch to a wider audience will hopefully help to iron out bugs and issues. Cheers, Eloy Paris.- |
From: Thomas M. <tma...@sa...> - 2012-11-14 02:43:04
|
No, it's doesn't have a user switch. It has a button, like the (old) LampLinc. On 2012-11-13, at 9:31 PM, Marc MERLIN <ma...@me...> wrote: > On Tue, Nov 13, 2012 at 09:23:26PM -0500, Thomas MacLean wrote: >> HiAll, >> >> I notice that the InlineLinc does not appear in the list of device tags. I suppose is it functionally similar to a LampLinc. Has anyone tried it? > > Wait, doesn't it come with a switch? If so it should be a switchlinc. > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet cooking > Home page: http://marc.merlins.org/ > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Marc M. <ma...@me...> - 2012-11-14 02:51:31
|
On Tue, Nov 13, 2012 at 09:42:51PM -0500, Thomas MacLean wrote: > No, it's doesn't have a user switch. It has a button, like the (old) LampLinc. Then Lamplinc is probably is. You can try both if that was wrong :) Marc > On 2012-11-13, at 9:31 PM, Marc MERLIN <ma...@me...> wrote: > > > On Tue, Nov 13, 2012 at 09:23:26PM -0500, Thomas MacLean wrote: > >> HiAll, > >> > >> I notice that the InlineLinc does not appear in the list of device tags. I suppose is it functionally similar to a LampLinc. Has anyone tried it? > > > > Wait, doesn't it come with a switch? If so it should be a switchlinc. > > > > Marc > > -- > > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > > Microsoft is to operating systems .... > > .... what McDonalds is to gourmet cooking > > Home page: http://marc.merlins.org/ > > > > ------------------------------------------------------------------------------ > > Monitor your physical, virtual and cloud infrastructure from a single > > web console. Get in-depth insight into apps, servers, databases, vmware, > > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > > Pricing starts from $795 for 25 servers or applications! > > http://p.sf.net/sfu/zoho_dev2dev_nov > > ________________________________________________________ > > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Jim D. <ji...@du...> - 2012-11-16 01:26:08
|
On 11/14/2012 08:58 PM, John wrote: > I get the loop detected error on at least one set of my linked switches > (from pretty much beginning of the new insteon code). I did some > searching on this error and but didn't pursue it further. > I too get these message occasionally, but nothing wrong seems to happen with lighting or scenes as a result. Jim |
From: Marc M. <ma...@me...> - 2012-11-17 16:26:08
|
On Thu, Nov 15, 2012 at 08:25:58PM -0500, Jim Duda wrote: > On 11/14/2012 08:58 PM, John wrote: > > > I get the loop detected error on at least one set of my linked switches > > (from pretty much beginning of the new insteon code). I did some > > searching on this error and but didn't pursue it further. > > I too get these message occasionally, but nothing wrong seems to happen > with lighting or scenes as a result. I get it too once in a while, and I got it with the old insteon code too. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Jim D. <ji...@du...> - 2012-11-07 15:23:39
|
Marc MERLIN <marc_mh <at> merlins.org> writes: > Considering that we have svn left behind now, I actually think that it > would be ok to collapse the two branches and make the new insteon code the > master code. > If it somehow breaks someone, they're not dead in the water because they can > still fall back to the old code in svn, report the problem, and hopefully > someone can help fix this in the new code. > I agree 100%. I haven't used the trunk in a long time. I find the insteon branch very stable. I myself don't need the automatic link management as the number of times I add a new Insteon device is rather rare. I say we cut-the-cord on the older insteon implementation, move forward with the insteon branch, and add the missing pieces required, falling back on SVN with the necessary code references to port. Regards, Jim |
From: Lieven H. <li...@li...> - 2012-11-07 21:21:12
|
Hi, I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon. https://github.com/hollie/misterhouse/pull/12 I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please? git clone gi...@gi...:hollie/misterhouse.git cd misterhouse git checkout -b branch_merge_phase1 origin/branch_merge_phase1 test and report back please If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me. Hope this branch works without big problems, then the merging operation is almost complete. I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. Kind regards, Lieven. Op 7-nov.-2012, om 16:05 heeft Eloy Paris <pe...@ch...> het volgende geschreven: > On 11/07/2012 09:35 AM, Marc MERLIN wrote: > > [...] > >> Considering that we have svn left behind now, I actually think that it >> would be ok to collapse the two branches and make the new insteon code the >> master code. > > I would agree with this. > >> If it somehow breaks someone, they're not dead in the water because they can >> still fall back to the old code in svn, report the problem, and hopefully >> someone can help fix this in the new code. >> >> So while I can't call myself the backup insteon maintainer, I think it's >> time to fold both branches at least in git since the possible problems >> this might cause are likely far outweighed by the cost of those 2 branches. > > Yes. > > Also, exposing the INSTEON stack in the insteon branch to a wider > audience will hopefully help to iron out bugs and issues. > > Cheers, > > Eloy Paris.- > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: John <jo...@to...> - 2012-11-08 00:47:56
|
On 11/07/12 15:20, Lieven Hollevoet wrote: > test and report back please Thanks! On first start of mh, there were no insteon debug messages indicating device scan. However, lights on/off worked. On restart I got what I expected. For example: 11/07/12 05:53:39 PM [Insteon::BaseObject] received status for $backyard with on-level: 0%, hops left: 0 However, I recall this happening with insteon branch previously and I attributed it to how things are (and beyond my current understanding). Tested: lircd interface turning on Insteon scene on/off (works) Tested: Serial Weeder interface (works) Tested: receive xpl message (works) After this I ran through things on plm and devices like syncing links. To be honest, it is not clear to me what these do. Stuff seems to work without those steps so maybe there is something persistent from last version and my testing is not conclusive. If there is docs that describe this let me know otherwise I will continue to go through the code. Nothing seems out of ordinary in logs. I will continue to work with it and report back if anything comes up. John |
From: Jim D. <ji...@du...> - 2012-11-08 01:05:14
|
On 11/07/2012 04:20 PM, Lieven Hollevoet wrote: > Hi, > > I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon. > > https://github.com/hollie/misterhouse/pull/12 > > I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please? > > git clone gi...@gi...:hollie/misterhouse.git > cd misterhouse > git checkout -b branch_merge_phase1 origin/branch_merge_phase1 > > test and report back please > > If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me. > > Hope this branch works without big problems, then the merging operation is almost complete. > > I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. I am up and running on this version. So far so good. Jim |
From: Alan W. <arw...@we...> - 2012-11-08 02:11:15
|
Wow, don't check in for a few days and lot occurs. I am in inadvertently on the old branch and running a lfs version of linux. From a NOOB status, can I assume: that I need to download git and compile it from source then use the commands further up the thread to checkout the new branch we are working on. Make the symlink change to point to the new branch Update my insteon.mht to a newer format? My network is not huge yet, but pushing 18 switches, devices, and moving onto the 20's soon. Should give it a bit of a shake out as well. |
From: John <jo...@to...> - 2012-11-08 02:28:06
|
On 11/07/12 19:05, Alan Womack wrote: > Wow, don't check in for a few days and lot occurs. > > I am in inadvertently on the old branch and running a lfs version of > linux. From a NOOB status, can I assume: > > that I need to download git and compile it from source > > then use the commands further up the thread to checkout the new branch > we are working on. If you just want to test, you do not need to use git. From the github site, you can select the branch "branch_merge_phase1" and then hit the ZIP button. You can extract that in a location you can point your symlink to. > > Make the symlink change to point to the new branch > > Update my insteon.mht to a newer format? Yes, you will want to update your Insteon items. You can refer to the wiki page for details on this. For sure back up your existing mht file first. |
From: Jim D. <ji...@du...> - 2012-11-08 02:11:34
|
On 11/07/2012 08:05 PM, Jim Duda wrote: > > I am up and running on this version. So far so good. I had to stop using this version. It appears something is wrong with xAP messages. I don't use much xAP, but some. One of my modules which listens for xAP messages is not getting them. I returned to the original insteon branch from git, and I'm getting xAP messages. I can debug in more detail at a later time. Maybe someone with more xAP requirements should test too. Regards, Jim |
From: Lieven H. <li...@li...> - 2012-11-08 08:13:49
|
Jim, On Thu, Nov 8, 2012 at 3:11 AM, Jim Duda <ji...@du...> wrote: > On 11/07/2012 08:05 PM, Jim Duda wrote: > > > > > I am up and running on this version. So far so good. > > I had to stop using this version. It appears something is wrong with > xAP messages. I don't use much xAP, but some. One of my modules which > listens for xAP messages is not getting them. I returned to the > original insteon branch from git, and I'm getting xAP messages. > > There was an update in mh.ini with new xAP-related settings. Amongst others, the built-in xAP hub is disabled by default. https://github.com/hollie/misterhouse/commit/8dba1524fcfa531be63affd46c64046862c71f7b You might need to look in that direction. Kind regards, Lieven. |
From: Jim D. <ji...@du...> - 2012-11-08 12:46:50
|
On 11/08/2012 03:13 AM, Lieven Hollevoet wrote: > > There was an update in mh.ini with new xAP-related settings. Amongst others, the built-in xAP hub is disabled by default. > https://github.com/hollie/misterhouse/commit/8dba1524fcfa531be63affd46c64046862c71f7b > > You might need to look in that direction. > > Kind regards, > Lieven. > Lieven, Yes indeed, that was the issue. I am back up and running live on branch_merge_phase1 My xAP messages are restored with the internal hub turned on. linux> git branch -v * insteon 8dba152 [ahead 42] Merge branch 'master' into branch_merge_phase1 master a08416e Merge pull request #11 from hollie/fix_issue_10 Regards, Jim |
From: Thomas M. <tma...@sa...> - 2012-11-14 03:20:03
|
Hi Lieven, not to confuse the matter too much , but... can you explain how I should pull your "branch_merge_phase1" from your repo into my fork? I had managed to re-synch up with: git remote add original https://github.com/hollie/misterhouse.git git pull original master git push origin master but then I got a bit lost trying to get your branch into my fork. One bad route is: git pull original branch_merge_phase1 .. this pulled your branch into my master. It complained about a bad merge for xPL_Items.pm. I think I'd rather have branch that matches yours, no? Thanks for any guidance. Regards, Tom On 2012-11-07, at 4:20 PM, Lieven Hollevoet <li...@li...> wrote: > Hi, > > I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon. > > https://github.com/hollie/misterhouse/pull/12 > > I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please? > > git clone gi...@gi...:hollie/misterhouse.git > cd misterhouse > git checkout -b branch_merge_phase1 origin/branch_merge_phase1 > > test and report back please > > If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me. > > Hope this branch works without big problems, then the merging operation is almost complete. > > I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. > > Kind regards, > Lieven. > > Op 7-nov.-2012, om 16:05 heeft Eloy Paris <pe...@ch...> het volgende geschreven: > >> On 11/07/2012 09:35 AM, Marc MERLIN wrote: >> >> [...] >> >>> Considering that we have svn left behind now, I actually think that it >>> would be ok to collapse the two branches and make the new insteon code the >>> master code. >> >> I would agree with this. >> >>> If it somehow breaks someone, they're not dead in the water because they can >>> still fall back to the old code in svn, report the problem, and hopefully >>> someone can help fix this in the new code. >>> >>> So while I can't call myself the backup insteon maintainer, I think it's >>> time to fold both branches at least in git since the possible problems >>> this might cause are likely far outweighed by the cost of those 2 branches. >> >> Yes. >> >> Also, exposing the INSTEON stack in the insteon branch to a wider >> audience will hopefully help to iron out bugs and issues. >> >> Cheers, >> >> Eloy Paris.- >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Central: Instant, anywhere, Remote PC access and management. >> Stay in control, update software, and manage PCs from one command center >> Diagnose problems and improve visibility into emerging IT issues >> Automate, monitor and manage. Do more in less time with Central >> http://p.sf.net/sfu/logmein12331_d2d >> ________________________________________________________ >> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 >> > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Lieven H. <li...@li...> - 2012-11-14 09:57:43
|
Hello Tom, sure. So, what you basically did if I follow the flow of the commands you listed: > git remote add original https://github.com/hollie/misterhouse.git 1) you added a link to my repo, which is ok > git pull original master 2) you get all the changes from my master branch and merge them into your local master (-> this is what 'pull' does. pull=fetch+merge) > git push origin master 3) you published the changes applied in step 2 to your remote fork. Up to here all is fine. > One bad route is: git pull original branch_merge_phase1 .. this pulled your branch into my master. It complained about a bad merge for xPL_Items.pm. > I think I'd rather have branch that matches yours, no? But the next command is indeed not the way to go as you noticed. Basically what you did with the command is: you ask git to take my proposed new version of the insteon branch (=insteon+ all changes that were made to master since the branch between master and insteon) and you asked to to merge it into your master branch. If you followed the insteon/master merge thread you noticed I proposed to first bring insteon up to date with master (phase1) and only in a second stage we could then apply the up-to-date insteon back into master (phase2). I do indeed expect some conflicts to occur there, and I'm willing to take a shot at merging, but I would first like that more people test out the modified insteon branch. Sorry for all this text, but I'm trying to give you the context so that you see why the operation you tried to do did not work out as you expected. Now the cool thing with git is that I can try exactly the same commands as you are going to execute them on your pc, so I can duplicate your working environment to help you further. There are two ways to go: you can make a new clone and start from there, or you can fix the current clone you have (the one that has the merge changes in it). I'll explain the first way to go (so starting from scratch) as this will also help other mailing list members if they want to get the 'phase1' branch on their computer. 1) get a clone of your fork git clone gi...@gi...:tmaclean/misterhouse.git cd misterhouse Note 1: On my computer I use the read-only access link to your repo of course (git://github.com/tmaclean/misterhouse.git) Note 2: people who only want to try out the new insteon branch, there is an easy way just for testing that is descibed below *) 2) add the link to the upstream repo where you want to fetch changes from git remote add upstream git://github.com/hollie/misterhouse.git 3) get all changes from upstream but do not merge them git fetch upstream You might want to do a 'git pull upstream insteon' here as your fork is not up to date with the upstream repo. 4) now create the branch you want to create in your local clone: git checkout -b branch_merge_phase1 upstream/branch_merge_phase1 Optionally commit it to your remote fork if you're happy with the results. git push origin branch_merge_phase1 There are some steps, but they are only required because you have your fork and you want to keep it up to date. *) For people who just want to test out the new inteon branch merged with master changes, you only need to execute 2 commands: 1) git clone git://github.com/hollie/misterhouse.git misterhouse_testbranch 2) git checkout -b test_phase1 origin/branch_merge_phase1 I hope this helps you further. As a question to all: when will we decide branch_merge_phase1 has been tested enough to go for an actual merge with insteon? I would like to do this first before spending time in merging the updated insteon with master. Kind regards, Lieven. Op 14-nov.-2012, om 04:19 heeft Thomas MacLean <tma...@sa...> het volgende geschreven: > Hi Lieven, > > not to confuse the matter too much , but... can you explain how I should pull your "branch_merge_phase1" from your repo into my fork? > > I had managed to re-synch up with: > > > but then I got a bit lost trying to get your branch into my fork. > > > Thanks for any guidance. > > Regards, > Tom > > > On 2012-11-07, at 4:20 PM, Lieven Hollevoet <li...@li...> wrote: > >> Hi, >> >> I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon. >> >> https://github.com/hollie/misterhouse/pull/12 >> >> I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please? >> >> git clone gi...@gi...:hollie/misterhouse.git >> cd misterhouse >> git checkout -b branch_merge_phase1 origin/branch_merge_phase1 >> >> test and report back please >> >> If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me. >> >> Hope this branch works without big problems, then the merging operation is almost complete. >> >> I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. >> >> Kind regards, >> Lieven. >> >> Op 7-nov.-2012, om 16:05 heeft Eloy Paris <pe...@ch...> het volgende geschreven: >> >>> On 11/07/2012 09:35 AM, Marc MERLIN wrote: >>> >>> [...] >>> >>>> Considering that we have svn left behind now, I actually think that it >>>> would be ok to collapse the two branches and make the new insteon code the >>>> master code. >>> >>> I would agree with this. >>> >>>> If it somehow breaks someone, they're not dead in the water because they can >>>> still fall back to the old code in svn, report the problem, and hopefully >>>> someone can help fix this in the new code. >>>> >>>> So while I can't call myself the backup insteon maintainer, I think it's >>>> time to fold both branches at least in git since the possible problems >>>> this might cause are likely far outweighed by the cost of those 2 branches. >>> >>> Yes. >>> >>> Also, exposing the INSTEON stack in the insteon branch to a wider >>> audience will hopefully help to iron out bugs and issues. >>> >>> Cheers, >>> >>> Eloy Paris.- >>> >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Central: Instant, anywhere, Remote PC access and management. >>> Stay in control, update software, and manage PCs from one command center >>> Diagnose problems and improve visibility into emerging IT issues >>> Automate, monitor and manage. Do more in less time with Central >>> http://p.sf.net/sfu/logmein12331_d2d >>> ________________________________________________________ >>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 >>> >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Central: Instant, anywhere, Remote PC access and management. >> Stay in control, update software, and manage PCs from one command center >> Diagnose problems and improve visibility into emerging IT issues >> Automate, monitor and manage. Do more in less time with Central >> http://p.sf.net/sfu/logmein12331_d2d >> ________________________________________________________ >> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |