> Thanks for finding this. I'm not sure what else is broken so if you > keep going that would be cool. I will be tweaking the document later > tonight to fix the procedure. So please update and see if the new > procedure works better.
Sure thing. It's been a long time since I touched TinyOS, and I'm trying to get back into it by setting up a dev environment on OSX (Mountain Lion). > The intent is your changes are concentrated on the > gh:FlyingCampDesign/tinyos-main(cw) branch. While > gh:FlyingCampDesign/tinyos-main(master) is used to continue to track the > upstream from gh:tinyos/tinyos-main(master). So I don't think we need > the gh:FlyingCampDesign/tinyos-main(master-up) branch. You can always > reference the upstream master branch via the reference up/master. > > As new changes come in from the mainline, you update your local copy of > master by merging from up/master. It should always be a fast-forward. OK, this is starting to make more sense. Questions: 1) Since you can always reference the upstream master via up/master, why the need to track it in roberthunter/tinyos-main(master)? (i.e why does roberthunter/tinyos-main(master) need to exist?) It seems like the recommended place for personal dev is roberthunter/tinyos-main(rh), so it seems like extra chores to keep the roberthunter/tinyos-main(master) up to date when it's not really necessary? 2) So is the following workflow correct? [initial setup] (fork repo) $ git clone [email protected]:roberthunter/tinyos-main.git tinyos-2.x $ cd tinyos-2.x $ git remote add up git://github.com/tinyos/tinyos-main $ git fetch up $ git checkout -b rh <- create personal branch [daily workflow] $ git checkout rh <- checkout personal branch $ git fetch up <- grab the latest changes from gh:tinyos/tinyos-main(master) $ git rebase up/master <- rebase local(rh) branch onto latest changes in up/master _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
