[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix #define logic regarding info format handling

From: Mark D. Baushke
Subject: Re: [PATCH] Fix #define logic regarding info format handling
Date: Thu, 21 Sep 2006 17:34:27 -0700

Hash: SHA1

Hi C. Michael Pilato,

I have committed your suggested patch to the CVS sources.

        Thank you,
        -- Mark

C. Michael Pilato <address@hidden> writes:

> This is totally a drive-by patch.  I happened to be reading this section
> of code, and something didn't look quite right.  I admit a general
> ignorance of the CVS codebase, but I hope that doesn't get in the way of
> someone knowledgeable evaluating this patch.
> The code segment in question is this from commit.c:
>     /* On success, retrieve the new version number of the file and
>        copy it into the log information (see logmsg.c
>        (logfile_write) for more details).  We should only update
>        the version number for files that have been added or
>        modified but not removed since classify_file_internal
>        will return the version number of a file even after it has
>        been removed from the archive, which is not the behavior we
>        want for our commitlog messages; we want the old version
>        number and then "NONE, unless UseNewInfoFmtStrings has
>        been specified in the config.  Expose the real version in that
>        case and allow the trigger scripts to decide how to use it.  */
>     if (ci->status != T_REMOVED
>         || config->UseNewInfoFmtStrings
> #endif
>         )
>     {
>     ...
> My understanding of that somewhat confusing comment is that the
> new-style info handling doesn't care if ci->status is T_REMOVED or not
> -- it will always populate the new revision slot.  Old-style info
> handling (which requires both support for such things, and configuration
> that dictates it), doesn't want the new revision for removed things --
> it just wants the old revision and then "NONE".  This all seems like a
> reasonable thing to do, too.  The comment is a bit confusing because it
> seems to run like "behavior unless condition, unless condition".
> (Comparing with the 1.11.21 sources, I can see that that final ", unless
> condition" segment was just tacked onto a version of this comment that
> predates new info format styles altogether.)
> The code, however, doesn't seem to reflect that understanding, hence the
> patch.  Of course, if my understanding of the comment is wrong, then my
> patch is probably likewise wrong.
> I'm not subscribed to this list, but would love to be Cc:ed on
> follow-ups to this thread.  Also, I'm happy to submit a follow-up patch
> that fixes the comment a little more comprehensible.  Thanks.
> -- 
> C. Michael Pilato <address@hidden>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
Version: GnuPG v1.4.4 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]