Development strategy

[Lea Wiemann <lewiemann@gmail.com>]

Hi everyone,

[For those uninitiated, this is about my GSoC project about adding 
caching to Gitweb, on which I am currently working full-time; my branch 
is here: http://repo.or.cz/w/git/gitweb-caching.git]

I'm seeing a process-wise problem arising with my current work on Git.pm 
and Gitweb, in that I'm producing patches at a higher frequency than the 
developer community can handle.  Right now, I have a stack of 7 patches 
that haven't been "approved" in any way (i.e. either they are under 
discussion or nobody has reviewed them) and that my future work will 
depend on.  Chronologically,

! 2f15087248 perl/Git.pm: add get_hash method
   abd799435c gitweb: use Git.pm, and use its get_hash method
! 5e53e2e67e t/test-lib.sh: add test_external
! c5c97f896c Git.pm: fix documentation of hash_object
! 8db2d73809 test suite for Git.pm
   261a54ff5b gitweb: removed unused parse_ref method [not posted yet]
   e9166526a3 Git.pm: add get_type method [not posted yet]

The patches marked "!" I cannot change without breaking at least one 
subsequent patch, so every time I want to make a change to one of those, 
I also need to change at least one subsequent commit, and worse, 
resubmit it to the mailing list.  (E.g. the the recent rename from 
parse_rev to get_hash necessitated two extra patches to accommodate the 
change.)

If I keep on committing revisions like I'm doing right now, I'll end up 
with a long queue of interdependent patches of which only the newest few 
are easily changeable.  Here are some ideas to prevent this:

1) My current patch frequency is probably too high, in particular if 
minor changes (like method renames or documentation changes) cause 
re-posts of patches.  Hence, I suggest that I stay on my branch for now 
and only post patches on which I actually want feedback, without 
reposting corrected versions after getting feedback.  That is, no 
patches just for "please someone approve this".

2) I should probably also try to squash patches into larger ones.  This 
will make it easier to make changes in older commits, since I don't have 
to edit several commits, and it reduces the probability of merge 
conflicts.  I'm not sure how much squashing is appropriate though: For 
example, would it be okay to squash a fix like "Git.pm: fix 
documentation of hash_object" into a larger "Git.pm: add and fix several 
methods" commit, where I only mention the documentation-fix in the log 
message?  It would certainly be helpful in that it reduces the number of 
conflicts, but it will make the logs coarser.

-- Lea