I think that I have settled on an approach to the menu system in the Dart version of the ICE Code Editor. I need to convert the rest of the dialogs in the
dialog-classes branch over to the strategy pattern before I am ready to merge the changes back into master, but first, I have a good problem to have™. Both the master branch and the dialog-classes branch have undergone significant work in the same area over the past few days. The best way to fix this, I think is to git rebase the dialog-classes branch back onto master. Currently, they diverged back at commit
b0ace77:➜ ice-code-editor git:(dialog-classes) git lola * 2ca6894 (HEAD, origin/dialog-classes, dialog-classes) Move MenuItem class into its own file * c49f3d4 Try OpenDialog as a strategy * 5512abb Private methods to contruct menu objects * 0275d60 Rename the Projects menu as Open * b10ae98 Rename projects dialog as open dialog * 630b839 Extract sub-menus and dialogs out into classes * 1d91d06 Account for renamed in newly rebased code * bdf1554 Internal script to generate docs * 1f85bdc Extract ProjectsDialog into its own file * 0b8ecb2 Pull the project menu out into a class | * 38ab658 (origin/master, master) rename feature: the rename input filed has focus | * ba06eac get started on the rename feature | * 40ffbb9 Improve the make-a-copy naming |/ * b0ace77 Merge pull request #3 from gempesaw/makeACopy |\ | * d11c704 Add automatic focus and pre-populate makeCopy menu item | * fbf286d Fix focus for share menu item |/ * 3e4bdcc Markdown typo * da53f79 Implement the Make Copy feature ...(
git lola is an alias for log --graph --decorate --pretty=oneline --abbrev-commit --all)I need to take the
0b8ecb2 Pull the project menu out into a class commit and make it so that git thinks of it as having been made after 38ab658 (origin/master, master) rename feature: the rename input filed has focus, not the current b0ace77 branch point. This is what git rebase does.I am going to get git conflict from this, but that will either happen now or when I merge the branch back into master. I'd rather get it out of the way now.
So, I start:
➜ ice-code-editor git:(dialog-classes) git rebase master First, rewinding head to replay your work on top of it... Applying: Pull the project menu out into a class Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging lib/full.dart CONFLICT (content): Merge conflict in lib/full.dart Failed to merge in the changes. Patch failed at 0001 Pull the project menu out into a class When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort".Yup.
If I take a look at the conflicting
lib/full.dart, I find pretty much what I expected. The conflict is due to removing code in the branch from a section of lib/full.dart that was under active development:class Full {
// lots of code that doesn't conflict...
<<<<<<< HEAD
Element get _projectsMenuItem { /* ... */ }
_openProjectsMenu() { /* ... */ }
_openProject(title) { /* ... */ }
Element get _renameMenuItem { /* ... */ }
_openRenameDialog(){ /* ... */ }
_renameProjectAs(String projectName){ /* ... */ }
String get _currentProjectName{ /* ... */ }
=======
>>>>>>> Pull the project menu out into a class
// even more code that doesn't conflict...
}I don't think that I made any changes in master to the project menu code and I definitely removed it from the dialog class branch. I think the conflict probably arose because of the rename menu code, which definitely is new in master. So I remove the projects code and leave the rename code in place. I then resume normal rebase operations:➜ ice-code-editor git:(38ab658) ✗ git add lib/full.dart ➜ ice-code-editor git:(38ab658) ✗ git rebase --continue Applying: Pull the project menu out into a class Applying: Extract ProjectsDialog into its own file Applying: Internal script to generate docs Applying: Account for renamed in newly rebased code ...Nothing is ever lost in git, so there is not much danger in removing that projects code. I also have an excellent test suite that has been driving all of my functionality so I feel even safer. In fact, I work through a few more simlilar conflicts, run my test suite and find:
Exception: Class 'Full' has no instance getter '_store@0x4729ef0'. NoSuchMethodError : method not found: '_store@0x4729ef0' Receiver: Instance of 'Full' Arguments: []I get a bunch of errors like that. Thankfully they are all fixed by converting the
store instance variable from private (indicated with a leading underscore) to a public instance variable in some of the code that came from master. With that, I have my entire test suite passing again:All 52 tests passed. unittest-suite-successI spent the rest of the evening converting any straggler dialogs to the new class-based approach and even adding new ones. I will merge back into master tomorrow. I can sleep on it safe in the knowledge that, even if any fixes are added to master, my dialog-classes branch is close enough that a merge should be a quick affair.
Day #765
Funny, I use `git lol'.
ReplyDeleteI've got `git lol` as well too -- it's the same command, but without the --all option so that it only shows the current branch. We must have found the same tutorial at some point :)
Delete