All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Doug Kelly <dougk.ff7@gmail.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)
Date: Tue, 15 Dec 2015 18:32:07 -0500	[thread overview]
Message-ID: <20151215233207.GA30294@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqq8u4ve3at.fsf@gitster.mtv.corp.google.com>

On Tue, Dec 15, 2015 at 02:48:42PM -0800, Junio C Hamano wrote:

> * dk/gc-more-wo-pack (2015-11-24) 3 commits
>  - gc: Clean garbage .bitmap files from pack dir
>  - t5304: Add test for .bitmap garbage files
>  - prepare_packed_git(): find more garbage
> 
>  Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
>  .bitmap and .keep files.
> 
>  Waiting for review.

I just read through and made some comments.

Note that I think there was a re-roll of the first patch after I picked
up the original:

  http://article.gmane.org/gmane.comp.version-control.git/281759

Hopefully Doug will re-post the whole series after taking a look at my
comments.

> * jc/strbuf-gets (2015-10-28) 17 commits
> [...]
> 
>  Teach codepaths that communicate with users by reading text files
>  to be more lenient to editors that write CRLF-terminated lines.
>  Note that this is only about communication with Git, like feeding
>  list of object names from the standard input instead of from the
>  command line, and does not involve files in the working tree.
> 
>  Waiting for review.

I like the intent here, but I was a little disappointed that we end up
with two almost identical strbuf functions. But even if the ultimate
endgame is to drop back to one, the conservative route is to keep them
both until all new code paths have "opted in" to the new behavior.
However, I found the naming confusing: it was not at all clear to me
which of strbuf_gets and strbuf_getline did the CRLF-munging. Perhaps
it would be more obvious if the new one was strbuf_getline_crlf or
something. I dunno.

-Peff

  parent reply	other threads:[~2015-12-15 23:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-15 22:48 Junio C Hamano
2015-12-15 23:16 ` Stefan Beller
2015-12-15 23:32 ` Jeff King [this message]
2015-12-15 23:34   ` Junio C Hamano
2015-12-15 23:36   ` Junio C Hamano
2015-12-15 23:44     ` Junio C Hamano
2015-12-16  0:50       ` Jeff King
2015-12-16 15:58       ` Johannes Schindelin
2015-12-16  6:58 ` Torsten Bögershausen
2015-12-16 18:04   ` Junio C Hamano
2015-12-21 15:31     ` Torsten Bögershausen
2015-12-18 13:23 ` SZEDER Gábor
2015-12-21 16:54   ` Junio C Hamano

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=20151215233207.GA30294@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=dougk.ff7@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --subject='Re: What'\''s cooking in git.git (Dec 2015, #05; Tue, 15)' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.