Ancor wrote: > I've also rearranged some files in ASexport to use Rails autoloader. > > I've never used GitHub, but this seems to be a good moment to start. > This weekend I'll fork active_scaffold_export so both of us can work > on a 2.2/2.3 enabled active_scaffold_export. >
Hi, any chance you could mail over a tar.gz of your new files to me privately? Wanting to work on this over the weekend anyway However, I think you struck the nail on the head with the class_eval What I don't get is whilst I agree with your diagnosis that ASE is defining the class initially, I don't understand why AS doesn't then effectively re-open that class and insert it's own methods. Probably I misunderstand meta programming with regards to classes and modules, but seems like AS should simply then re-open the class and insert it's own methods? I guess than an explicit include would also work here (although have other problems). class_eval seems a bit yucky, but not sure if there is some better way to defeat the auto loader here? What files did you move around though? Seems pretty sane as it is? Now, github, do this: - Create a new account - Then click fork on my repo ( http://github.com/ewildgoose/active_scaffold_export/tree/master ) - Now on your machine (use msysgit for windows, OSX and Linux are obvious), use: git clone http://your_repo_url - To change branches then just "git checkout branchname" - Suggest that you always keep master branch *pristine*. Intead do "git checkout -b wip master" to create a new branch wip based on master - Git is wonderfully flexible to just create branches every few mins if you wish, you can diff between branches and even move commits around between branches so incredibly easily. So if you have an idea, just create a fork, p*ss around, commit, go back to where you were, try something else, then years later you can grab those commits and actually transplant them onto the head of whatever you are working on today (that last bit is what's quite amazing) - To commit your new branch you need to explicitly push it back because it's not yet on the server (you can have loads more private branches on your local repo than on the server). "git branch -m wip patch_queue" renames your wip branch to something sensible, then "git push origin patch_queue" to send it up to the server - useful things are if you are in a branch then "git cherry some_other_branch" shows you your commits not on the other branch (can work in reverse). - "git cherry-pick some_commit" will grab a commit from some other branch and stick it in this branch - "git rebase master" is dangerous and powerful. It will merge all changes from master, THEN it will mangle all your patches in this branch and rewrite them so that they work against master... Never do this for a live branch other people are following or you break their repo, but for private patches that you want to keep adapted against the live tree it's fantastic! No more patch1, then patch1updated, patch1mergeagain and trying to figure out the net change years later - instead you just have the one single commit floating around such that it applies against the latest code Good luck Ed W --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ActiveScaffold : Ruby on Rails plugin" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/activescaffold?hl=en -~----------~----~----~----~------~----~------~--~---
