Re: [PATCH 2/2] Add Author and Documentation sections to git-for-each-ref.txt

[Jeff King <peff@peff.net>]

On Sat, Mar 12, 2011 at 10:34:08PM -0800, Junio C Hamano wrote:

> I see you rebased your jk/doc-credits topic at GitHub but haven't queued
> this one yet, so I won't be pulling, but give me a holler when the branch
> is ready to be pulled into 'master'.  I'll then push the result out after
> running final "make doc" check on a few platforms I have and eyeballing
> the output.

It's pushed now. I rebase my topics aggressively on top of master (which
you saw), but I don't always push out regularly. Since my main output is
patches to the list, in general I assume nobody is actually looking at
my topics directly. :) Let me know if some other strategy would be
better[1].

I've done a perfunctory check over the changes, but there are a lot of
them, so another set of eyeballs on the output is appreciated.

-Peff

[1] I have mixed feelings about the aggressive rebasing. Our 'master' is
pretty stable, so I don't feel the need to build off the last tagged
release. But rebasing a lot does make it hard for others to follow the
topic, and it makes it hard to organize my work with you queue in pu,
and then merge to 'next' and 'master'. However, I haven't found a
satisfactory solution to tracking patches as they move through the
workflow of local development, sent to list, and applied upstream.

Git-cherry sort of does this, but patch-ids miss a lot of cases: patches
tweaked in transit, patches applied on a different commit, or even
patches taken partially or split up. So I rebase frequently, and as
patches get picked up in master, the branches dwindle to empty.
Suggestions welcome if anybody else has figured out something clever.

-Peff