bug-standards
[Top][All Lists]
Advanced

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

Re: Circumstances in which ChangeLog format is no longer useful


From: Joseph Myers
Subject: Re: Circumstances in which ChangeLog format is no longer useful
Date: Tue, 1 Aug 2017 12:03:42 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Tue, 1 Aug 2017, Rical Jasan wrote:

> $ git log -L :<funcname>:<file>
> 
> syntax, but I haven't used it enough in practice to know how reliable it
> is.  Neither do I know how that translates to tracking variables,
> macros, structs, or other data types of interest, if at all.

If the default funcname regular expression (lines starting with letters, 
underscores or $) isn't suitable, you can provide xfuncname configuration 
in .gitattributes.

> Do you know of a good way to cull changes to, for example, a struct,
> where the diff would only show changes to its members?  IOW, an
> alternative to:
> 
>             (mcontext_t): Use __ctx in defining fields.
> 
> For the example patch being discussed, the only reason it would show up
> with `git log -G mcontext_t' is because of the ChangeLog entry---there
> are otherwise no lines in the diff where an added or removed line
> contains mcontext_t.  The only reason it shows up with `git log
> --grep=mcontext_t' is again because of the ChangeLog format segment of
> the commit message---it is not contained within the textual description.

(a) It appears in the diff context (in this case).

(b) There is, of course, no guarantee in such a case of whether a 
ChangeLog entry would use the struct tag or the typedef name to refer to 
the named entity, in cases of "typedef struct foo { } foo_t;"; the format 
doesn't allow for a single entity having multiple names.  If it were the 
struct tag you wanted to find, git log -L would work.

(c) I think it's reasonable to say that for some questions you write a 
program that examines the changes between two revisions to decide if they 
have the exact property you are interested in, then run that over the 
history (and I think looking for changes to named entities, in cases that 
aren't covered by tools such as git log -L or searching for regular 
expressions in the diffs themselves, is a sufficiently specialized case 
for that to be reasonable).  Since you have the history in a DVCS, this 
can be done.

-- 
Joseph S. Myers
address@hidden



reply via email to

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