Merging strategy for extending Git.pm (was: [PATCH] perl/Git.pm: add rev_parse method)

Petr Baudis wrote:

(i) Tell Junio you would like the changes to stay in pu or next for now.
[...]
you will be getting immediate feedback about your changes as you go and 
your work will be useful at any point of time.

Junio, any comments on this?  Doing doing small iterations is great IMO, 
and I'll be doing it in any case.  However, right now I see three 
possible problems with merging to pu continuously (rather than keeping 
it on my branch and merging in large chunks):

1. I'm working full-time on this, so I might produce patches that 
loosely depend on one another at a peak rate of 2-3 per day.  (I can do 
other project-related stuff while my patches are waiting for review, but 
only so much of course.)  Do you have any experience with working with 
full-time developers on Git?  Do you see problems with my potentially 
high patch frequency?

2. I'll be changing my own API.  In other words, the API is really 
unstable while I work on this (with the only user of the API being 
Gitweb, which I'll update as I go).  Is that OK for the pu branch?

3. I try to be careful with my commits, but it might still cause more 
work for whoever reviews my patches, compared to reviewing larger 
chunks.  (That's because some of the stuff I write might end up being 
deleted or rewritten later.)

Apart from that, I think merging (and getting feedback) continuously is 
great.

So, comments would be much appreciated!

-- Lea