[cairo] [PATCH] _cairo_win32_surface_show_glyphs

[Baz]

On 05/01/07, Jonathan Watt <jwatt at jwatt.org> wrote:
> Hi Behdad,
>
> Thanks for the suggestions. I'd have a go at that if I didn't feel like I'm
> juggling too many things at once right now. (It also doesn't help that git gives
> me headaches whenever I try to do the "simplest" thing which makes me inclined
> to avoid it. It's a shame that git seems to make more advanced uses the default
> thereby requiring more detailed knowledge for the simple use cases. When I find
> the time I'll spend a few days learning how git works, then write some cairo git
> docs and come back to this (if no one else has addressed it by then).)
>
> -Jonathan

BTW Carl did a writeup before which explains git and cogito ('cg') quite well:
http://lists.freedesktop.org/archives/cairo/2006-February/006335.html

As a fellow git newbie, I found that using the cogito front-end makes
things a wee bit nicer but using 'stacked git' makes things better
still. After several cg-commits I've  usually got working code but
there's some reverts in there, the patch sequence should be changed to
make more sense, I could do with editing the commit messages, and I've
got some review comments back so the patches need changed. Before I
started using stacked git (aka 'stgit', or 'stg') I used to have a
directory full of patches and re-apply/regenerate them to keep them up
to date. Not any more.
http://www.procode.org/stgit/

Stacked git is a tool for managing your patch series (all your
uncommitted changes) on top of git. Before I explain how you get start
using that, here's what it looks like in action:

Moonstone:~/cairo brianewins$ stg series
+ atsui-glyph-scaling
+ atsui-glyph-path-rotation
+ atsui-cgbitmapcontext
+ atsui-glyph-surface-call
+ atsui-glyph-surface-impl
+ atsui-device-units
+ atsui-select-font-face
> atsui-cgpath-refactor
- atsui-glyph-path-surface-impl
- atsui-style-condition
- perf-diff-autoconf-options

I have 11 patches in my series, those are their names. The 7 marked
'+' and the one marked '>' are 'applied', ie they are in my working
copy but not committed. The '>' marks the 'top' patch, my current
edits will become part of this. The last 3 marked '-' are unapplied,
ie they're not in my working copy - stg is just keeping track until
I'm ready for them.

At this point, the 'stg push' command would apply the first unapplied
patch 'atsui-glyph-path-surface-impl', and 'stg pop' would unapply the
top patch - 'atsui-cgpath-refactor' - from my working copy, making
'atsui-select-font-face' the top. I can apply patches out-of order
too, eg:
stg push perf-diff-autoconf-options

If I want to just change the commit message for a patch, I can do, eg:
stg refresh -e atsui-device-units

NB, none of this is committed code in git. 'stg commit' commits your
applied patches and removes them from your patch series. You would do
this if you're ready to 'cg-push' some of your changes upstream, as
we'll see below.

This is all pretty nifty, but how do you get from committing dirty
changes with cg-commit to patches that stg can manage? The answer is
'stg uncommit', which undoes the commits on the branch, converting
them to applied patches. First initialise the current branch for use
with stgit. You only need to do this once:
stg init

Now undo the HEAD commit, replacing it with an applied patch called
'HEAD'. Since the patch is applied, your working copy is unchanged:
stg uncommit HEAD

Now rename  the patch called 'HEAD' to something sensible:
stg rename HEAD something-sensible

When converting my commits I did this as a one-liner so I could easily
repeat the command with different names for each patch, eg:
stg uncommit HEAD; stg rename HEAD perf-diff-autoconf-options;stg pop;cg-log

cg-log is showing me the log message so I can figure out a good name
for the next patch. Since I'm popping patches as I go I end up with a
pristine working copy. Some of those patches just represented reverts,
I'll get rid of them now:
stg delete atsui-revert-1
stg delete atsui-revert-2 (etc)

And now I'm back where we came in, with a series of patches ready to
apply. I can push (ie apply) patches or pop (unapply) them, or I can
tell stg to go do whatever pushes and pops it takes to make a patch I
want to clean up current:
stg goto perf-diff-autoconf-options

Finally you need to get your changes upstream. Either someone else
will commit your patch for you or you can push changes. As changes get
applied upstream you can do:

Unapply all patches, update working copy, try to reapply each patch in order:
stg pull

Some patches may now be empty if they were applied upstream. get rid of those:
stg clean

And then, if you're up-to-date and ready to push changes upstream,
commit all currently applied patches. The commit messages will be your
patch descriptions:
stg commit

Now push your changes as normal. NB Upstream won't see your unapplied
and uncommitted patches:
cg-push

Hope this is useful,
Baz