git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Mar 2011, #01; Wed, 9)
Date: Thu, 10 Mar 2011 17:46:09 -0500	[thread overview]
Message-ID: <20110310224609.GG15828@sigill.intra.peff.net> (raw)
In-Reply-To: <7v62rr933v.fsf@alter.siamese.dyndns.org>

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

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

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

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

      reply	other threads:[~2011-03-10 22:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-10  1:27 What's cooking in git.git (Mar 2011, #01; Wed, 9) Junio C Hamano
2011-03-10 22:46 ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110310224609.GG15828@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).