Re: [PATCH v2 0/7] Provide API to invalidate refs cache
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 11, 2011, 17:26 UTC
- Message-ID
- <7v4nzfh21o.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4E93D932.6020001@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 9 quoted lines
> On 10/11/2011 02:02 AM, Junio C Hamano wrote: > ... >> I could rebase your series, but it always is more error prone to have >> somebody who is not the original author rebase a series than the original >> author build for the intended base tree from the beginning. > > I don't mind rebasing this little series on jp/get-ref-dir-unsorted. > ... > Rebasing 78 patches is going to be a morass of clerical work.
I do not think it is "clerical" in the first place.
Realistically, I expect that a 50+ patch series that touch fairly an important part of the system to take 2 cycles and a half before it hits a released version, judging from our recent experience with the recursive merge fix-up series.
When we already have a patch that has been discussed well enough on the list to fix somebody's real world problem, can we afford to block it and give an exclusive write lock to part of the codebase for 2 cycles to your series, or anybody's for that matter?
> Is there any alternative?
I think an alternative is not to hold on to a series before it gets so large to make you feel adjusting to the needs to other changes in the codebase is "clerical". Commit often and early while developing the initial pass, re-read often and throughout the whole process looking for things you regret you would have done in early in the series that you didn't (aka "oops, here is a fixup for the thinko in the early patch in the series), and clean-up early while preparing to publish. Reorder the parts that you are more confident that they do not need to change to come early in the series, and unleash these early parts when you reach certain confidence level.
I think your iterate-refs series was an example of good execution. It made the codeflow a lot clearer by reducing the special casing of the submodule parameter. In your grand scheme of things (e.g. read only parts of the ref namespace as needed) you might consider it a mere side effect, but the series by itself was a good thing to have.
Sometimes you may feel that a part of your series when taken out of context would not justify itself like the iterate-refs series did, until later parts of the series start taking advantage of the change. But that is what commit log messages are for: e.g. "this change to encapsulate these global variables into a single structure does not make a difference in the current codebase, but in a later patch this and that callers will need additional pieces of information passed aruond in the callchain, and will add new members to the structure".
> ... So maybe > I brought this whole mess down on my own head :-(
No, it is not anybody's fault in particular. That's life and open source.