Re: What's cooking in git.git (Mar 2011, #01; Wed, 9)

From: Jeff King <peff@peff.net>
Date: Mar 10, 2011, 22:46 UTC
Message-ID: <20110310224609.GG15828@sigill.intra.peff.net>
In-Reply-To: <7v62rr933v.fsf@alter.siamese.dyndns.org>

On Wed, Mar 09, 2011 at 05:27:32PM -0800, Junio C Hamano wrote:

Show 6 quoted lines

> * jc/rename-degrade-cc-to-c (2011-01-06) 3 commits
>  . diffcore-rename: fall back to -C when -C -C busts the rename limit
>  . diffcore-rename: record filepair for rename src
>  . diffcore-rename: refactor "too many candidates" logic
> 
> Somebody said that this is an expensive no-op?

It was me, but that was not quite what I said. It is still useful to degrade "-C -C" to "-C". But the warning message is a no-op, because the only caller who turns it on is merge-recursive, which does not use "-C -C". It is probably still worth doing.

We may also consider turning on the warning message for "git diff". For "git log", I'm not so sure. It would perhaps be lost in the spew of output, but given that we send stderr to the pager these days, with some appropriate calls to fflush() we could make it appear in a sane place.

Show 9 quoted lines

> * jk/trace-sifter (2011-02-24) 6 commits
>   (merged to 'next' on 2011-03-09 at 07841db)
>  + trace: give repo_setup trace its own key
>  + add packet tracing debug code
>  + trace: add trace_strbuf
>  + trace: factor out "do we want to trace" logic
>  + trace: refactor to support multiple env variables
>  + trace: add trace_vprintf
>  (this branch uses jk/strbuf-vaddf; is tangled with ab/i18n-st and jn/status-translatable.)

Hmm, I was surprised to see this make it to next. I was planning a re-roll based on list comments (but I got held up in commit-notes, which I needed for my re-roll :) ). I can build on top, though.

Show 5 quoted lines

> * jk/format-patch-multiline-header (2011-02-23) 3 commits
>   (merged to 'next' on 2011-03-09 at f970fe3)
>  + format-patch: rfc2047-encode newlines in headers
>  + format-patch: wrap long header lines
>  + strbuf: add fixed-length version of add_wrapped_text

I have a patch to make "format-patch -k" preserve newlines in subjects; the result behaves sensibly with both "am" (which munges it to one line) and "am -k" (which preserves the newlines). Did we want to follow-up with that or no?

-Peff