Git-Scribe Rebase (Interactive)

‹prev | My Chain | next›

I more or less successfully rebased my fork of git-scribe onto upstream. There are still a few things that I need to check out, but I am left with 39 post-upstream commits. Some of them should probably be merged together, so I set off...

➜  git-scribe git:(master) git rebase -i upstream/master

Some of those commits are easy to squash together:

...
pick 24f4048 Grey background for code samples in epub
pick 1e28f14 Note on my fork
s c5c1cae Note on my fork
s f85b11c Note on my fork
s 63e6716 Note on my fork
pick a41d779 Support both admonition icons and cover image.
...

Others... not so much.

I am not sure I'd recommend this, but it is possible to re-order commits during an interactive rebase. The README was updated twice:

commit 84e5f4e45bfdaf7f93bec4a1f6922421a1c6f620
Author: Chris Strom 
Date:   Sun Apr 8 15:39:44 2012 -0400

    Note on my fork

commit 95c96f2501c4467fdd2a5a757db935a7619be60c
Author: Chris Strom 
Date:   Sun Aug 14 21:32:32 2011 -0400

    Updated README

But those commits are far apart in the history:

...
* 3f11995 Support both admonition icons and cover image.
* 84e5f4e Note on my fork
* c2d687b Grey background for code samples in epub
* 052d2e4 Admonition icons for PDF and epub.
....
* 4b89856 The generators only return boolean on completion.
* bf1bc34 Fix site html test.
* 95c96f2 Updated README
* 6d226fa Prepare the site in a separate sub-directory.
...

During yet another git rebase -i upstream/master, I can make those the last two commits, and squash them together:

...
pick 96e3541 Test tweak for source highlights
pick 95c96f2 Updated README
s 84e5f4e Note on my fork

In the end, I get it down to 24 commits between upstream and HEAD on my fork. The changes break down as:

• Note about my fork
• Test fixes (3)
• Admonition icons
• Epub: grey background for epub
• Minor fix: useless puts
• Post-commit hook for mobi (I use for ebok)
• TODO notes for PDF
• Same fix, different place (1)
• Renames image to images
• Build site separately to avoid conflict
• Support ZIP of three formats (git-scribe ebook)
• Remove temporary work files
• Code re-org -- I strongly prefer defining methods after their first use (6)
• Better mobi from epub (cover image, TOC) (2)
• Cover image in PDF
• PDF should be 7.5"x9"

I made the unfortunate choice to re-organize much of the generator code early on in my fork. It helped me out greatly when I was adding some of the features, but it leaves me in a tough position for tracking upstream. Compounding that is that the very first change in my fork—the 7.5" x 9" PDF form factor—conflicts with later upstream changes that switch XSLT processors.

Of the changes, I can definitely send a pull request to get rid of the useless puts statement. That was an annoyance every time I generated an updated gem. But aside from that, there is not much I can push in. Even the admonition icons do not apply well—it almost works until I realize that it relies on building up a docinfo file that I did last year to get the image cover in the epub. Bah.

I think that I am forced to call it a day here. I have addressed a few bugs in my fork as well as upstream. I have fixed various tests in both forks as well. I have improved the PDF and epub formats in my fork. Finally, I have rebased my fork back onto upstream so I have a better idea of what I have added and why. In the end, I want the features that I have added, so I am unlikely to strip things down to make a complete pull request possible. At the same time, I understand why upstream made the changes it made.

I have heard rumor that git-scribe is about to undergo significant change. That is probably for the best—especially if it pulls in the features of both forks without the baggage of either approach. /me waits eagerly.

In the meantime, it is time to get back to SPDY.


Day #351