Junio C Hamano <gitster@xxxxxxxxx> 于2021年3月21日周日 下午9:57写道： > > ZheNing Hu <adlternative@xxxxxxxxx> writes: > > > Do you think this is appropriate? > > > > @@ -370,5 +370,15 @@ int parse_buffer_signed_by_header(const char *buffer, > > struct strbuf *payload, > > struct strbuf *signature, > > const struct git_hash_algo *algop); > > +/* > > + * Calling `find_author_by_nickname` to find the "author <email>" pair > > + * in the most recent commit which matches "--author=name". > > + * > > + * Note that `find_author_by_nickname` is not reusable, because it haven't > > + * reset flags for parsed objects. The only safe way to use > > `find_author_by_nickname` > > + * (without rewriting the revision traversal machinery) is to spawn a > > + * subprocess and do find_author_by_nickname() in it. > > + */ > > Telling people not to add any new caller is good, but everything > after "because" does not make sense to me. > > I do not think calling find_author_by_nickname() in a subprocess > alone would not help somebody who wants to do this, either. We'd be > doing a moral equivalent of that call, but the result has to be > communicated back to the parent process, > What I am thinking about here is that `commit --trailer` itself jumps to a sub-process to do this, but this does depend on the fact that `interpret-trailers` itself does not have a traversal, and indeed should not be arbitrarily call it. > In the longer term, we'd probably want to have a pre-computed table > of contributors, like we have precomputed files for reachability > bitmaps, commit DAG topology, and such, but that is obviously far > outside of the scope of this series. > Indeed this will be a very big project. But `.mailmap` always makes me feel similar. > > +const char *find_author_by_nickname(const char *name);
