git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Deskin Miller <deskinm@umich.edu>
To: Petri Hodju <petri.hodju@yumesystems.com>
Cc: Jeff King <peff@peff.net>,
	git@vger.kernel.org, gitster@pobox.com,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] '%S' option for pretty printing to support --source
Date: Thu, 5 Mar 2009 14:41:44 -0500	[thread overview]
Message-ID: <86d4c5e00903051141u61a131beg26b3df95bafd65d3@mail.gmail.com> (raw)
In-Reply-To: <20090305091758.GC30445@coredump.intra.peff.net>

On Thu, Mar 5, 2009 at 04:17, Jeff King <peff@peff.net> wrote:
> On Thu, Mar 05, 2009 at 09:18:28AM +0200, Petri Hodju wrote:
>
>> +static void format_source(struct strbuf *sb, const struct commit *commit)
>> +{
>> +    if (commit->util)
>> +     strbuf_addstr(sb, (char *) commit->util);
>> +}
>> +
>
> Hmm. This is the second patch in the last few weeks to use commit->util
> to carry information for --pretty=format: (I am cc'ing Deskin Miller,
> who wrote the first).

Thanks Jeff.  Fortunately I managed to catch this one anyway.

Petri, the patch series from me which Jeff is referring to is viewable at

http://thread.gmane.org/gmane.comp.version-control.git/111524/

for reference.

I am in the middle of a move and ought to be packing right now, so
needless to say my git budget at the moment is pretty much nil, and
will be so for at least another week I'd guess.  This is to say, I've
not done any additional work in light of Jeff's or Dscho's comments on
my series, though I intend to once I'm relocated.

> They cannot both work, obviously. So we need to do one of:
>
>  - refactor the information out of commit->util to somewhere else
>
>  - allow multiple commit->util users somehow (which I think is a
>    potential performance problem -- the simplistic design is meant to
>    avoid things like allocation overhead)

I'm inclined to do as Dscho suggests here: glancing at the current
struct decoration usage briefly I think my reflog printing could work
that way with no problem.  However, this would largely ignore your
other comments about prettifying the pretty-printing code.  If a new
series using struct decoration isn't useful, let me know, otherwise
I'll plan on doing this once I have a chance.

>  - gracefully block concurrent use of conflicting features

I agree that any blocking should be graceful, but ultimately I find
the idea of disallowing features because they happen to use the same
underlying implementation distasteful.  With a little work we should
be able to allow both with no problem.

Deskin Miller

  parent reply	other threads:[~2009-03-05 19:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-05  7:18 [PATCH] '%S' option for pretty printing to support --source Petri Hodju
2009-03-05  9:17 ` Jeff King
2009-03-05 10:59   ` Johannes Schindelin
2009-03-05 19:41   ` Deskin Miller [this message]
2009-03-06  5:25     ` Jeff King

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=86d4c5e00903051141u61a131beg26b3df95bafd65d3@mail.gmail.com \
    --to=deskinm@umich.edu \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=petri.hodju@yumesystems.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).