Re: [PATCH] user-manual: Rewrite git-gc section for automatic packing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"W. Trevor King" <wking@xxxxxxxxxx> writes:

> I just read through the manual cover to cover, so I have a number of
> other fixes in the pipe (from which I've already submitted the
> receive.denyCurrentBranch patch).

Wonderful.

> ...  Should I bundle them all into a
> single series to reduce clutter on the list,...

I do think it makes much difference between a single series that
consists of 47 separate patches and a flood of 47 unrelated patches.
As long as it is not a single patch with 200 hunks, some of which
has to be redone repeatedly, I think it is fine either way.

Many of them may be a no-brainer to accept on the first try, while
some may have to be improved with the input from the list and will
be rerolled.  I would imagine the initial round would be:

	[PATCH v1 00/47] User manual updates
         [PATCH v1 01/47] user-manual: update description of 'xyzzy'
         [PATCH v1 02/47] user-manual: update description of 'frotz'
 	 ...
         [PATCH v1 47/47] user-manual: update description of 'nitfol'

and after reviewing, some of them need to be redone in v2; the cover
letter for v2 would say something like

	[PATCH v2 00/52] User manual updates

	The patches 01-17, 19, 22-36, 39, 42-47 are the same as in
        v1; 48-52 are new.

And people who missed the v1 review cycle may have a chance to look
at and respond to [PATCH v2 06/52] which may result in an update of
that patch to address issues that reviewers of the initial round may
have missed.

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]