Re: Merging strategy for extending Git.pm

Lea Wiemann [off-list ref] writes:

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?

As long as experienced people on the list review patches, I do not see a
problem.

    There seems to be a misconception (not you particularly but some parts
    of the list audience in general) that a review cycle of a patch sent
    to the list is a dialog between the submitter and me.  It is _NOT_.
    If it has rooms for improvements, other people would help you polish
    it, which happens often.  However, if it is very well done, I'd also
    like other people to say so after reviewing more often.

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?

It does not _have_ to even land on 'pu'.  Sending the patches to the list,
asking interesting parties to look at them, _and_ having people actually
review them is more valuable part.

If your series will become big, I do not mind (re)merging it from time to
time in 'pu' to give it a wider exposure.  If you want to go this route,
you would have a publicly fetchable repository of your own to house your
changes (repo.or.cz?).

I do not even mind merging the branch to 'next' if the series is 'next'
worthy, but that places heavier responsibility on your part to keep the
history of that branch clean.

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.)

One thing you could do, when sending out [PATCH v$n] for the value of $n
greater than 1, is to mention what the improvements are since the previous
round in the message (typically after the three-dash separator).  This
helps reviewers who have already seen your previous iteration.  The full
rationale of the change needs to be kept in the proposed commit log
message.

For example, your first patch may look like this:

	Subject: [PATCH] Git.pm: Add rev_parse() sub

	This adds a rev_parse() sub to return the 40-byte object name
        from given "extended SHA-1" expression.

	Signed-off-by: A U Thor [off-list ref]
	---
         <<diffstat and patch>>


Then after Pasky and others suggest improvements, your second message will
appear on the list:

	Subject: [PATCH v2] Git.pm: Add parse_rev()

	This adds 'parse_rev()' sub to return the 40-byte object name from
        given "extended SHA-1" expression.  It returns undef if the given
        string is malformed.

	Signed-off-by: A U Thor [off-list ref]
	---

         Changes relative to v1 are:
         
         * Fixed indentation;
         * Use -q to squelch non-fatal errors so that they do not leak
           to the STDERR;
         * Improved in-code documentation.

	 <<diffstat and patch>>

Some people also sends an interdiff between v$n-1 and v$n as a separate
message, and it helps reviewing when the change is big.