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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
