From: Lea Wiemann <lewiemann@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Cc: John Hawley <warthog19@eaglescrag.net>
Subject: Development strategy
Date: Mon, 02 Jun 2008 17:51:49 +0200 [thread overview]
Message-ID: <48441715.4010507@gmail.com> (raw)
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
next reply other threads:[~2008-06-02 15:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 15:51 Lea Wiemann [this message]
2008-06-02 18:30 ` Development strategy Sverre Rabbelier
2008-06-02 19:09 ` Jakub Narebski
2008-06-02 19:24 ` Sverre Rabbelier
2008-06-02 19:24 ` Johannes Schindelin
2008-06-02 19:39 ` Stephan Beyer
2008-06-02 20:02 ` Johannes Schindelin
2008-06-02 22:36 ` Lea Wiemann
2008-06-02 23:04 ` Sverre Rabbelier
2008-06-02 23:35 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48441715.4010507@gmail.com \
--to=lewiemann@gmail.com \
--cc=git@vger.kernel.org \
--cc=warthog19@eaglescrag.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).