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