Tuesday, May 28, 2013

Git Rebase and Dart

‹prev | My Chain | next›

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".

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. 
I 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


  1. Replies
    1. I'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 :)