git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 1/1] Upcast size_t variables to uintmax_t when printing
Date: Mon, 12 Nov 2018 07:26:00 -0500	[thread overview]
Message-ID: <20181112122600.GD3956@sigill.intra.peff.net> (raw)
In-Reply-To: <20181111101650.GA4471@tor.lan>

On Sun, Nov 11, 2018 at 11:16:50AM +0100, Torsten Bögershausen wrote:

> > I like the overall direction. I feel a little funny doing this step now,
> > and not as part of a series to convert individual variables. But I
> > cannot offhand think of any reason that it would behave badly even if
> > the other part does not materialize
> > 
> 
> Hej all,
> There may be some background information missing:
> - I did a 2-patch series based on this commit in pu:
>     commit 37c59c3e8fac8bae7ccc5baa148b0e9bae0c8d65
>     Author: Junio C Hamano <gitster@pobox.com>
>     Date:   Sat Oct 27 16:42:25 2018 +0900
> 
>         treewide: apply cocci patch
> 
> (that patch was never send out, see below)
> ....
> The week later, I tried to apply it on pu, but that was nearly hopeless,
> as too much things had changed on pu.
> I had the chance to compile & test it, but decided to take "part2" before
> "part1", so to say:
> Fix all the printing, and wait for the master branch to settle,
> and then do the "unsigned long" -> size_t conversion.
> That will probably happen after 2.20.

Ah, OK. I am fine with that approach. My thinking was that we'd see
individual functions and their callers converted, which is another way
to do it incrementally. But sometimes that ends up cascading and you end
up having to change quite a bit of the callstack anyway.

-Peff

      reply	other threads:[~2018-11-12 12:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-11  7:05 [PATCH v2 1/1] Upcast size_t variables to uintmax_t when printing tboegi
2018-11-11  7:28 ` Jeff King
2018-11-11 10:16   ` Torsten Bögershausen
2018-11-12 12:26     ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20181112122600.GD3956@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=tboegi@web.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).