On Tue, Jun 08, 2021 at 06:16:57PM -0400, Randall S. Becker wrote: > > On June 8, 2021 6:11 PM, Emily Shaffer wrote: > >It can be useful to tell who invoked Git - was it invoked manually by a user via CLI or script? By an IDE? In some cases - like 'repo' tool - > >we can influence the source code and set the GIT_TRACE2_PARENT_SID environment variable from the caller process. In 'repo''s case, > >that parent SID is manipulated to include the string "repo", which means we can positively identify when Git was invoked by 'repo' tool. > >However, identifying parents that way requires both that we know which tools invoke Git and that we have the ability to modify the source > >code of those tools. It cannot scale to keep up with the various IDEs and wrappers which use Git, most of which we don't know about. > >Learning which tools and wrappers invoke Git, and how, would give us insight to decide where to improve Git's usability and performance. > > > >Unfortunately, there's no cross-platform reliable way to gather the name of the parent process. If procfs is present, we can use that; > >otherwise we will need to discover the name another way. However, the process ID should be sufficient to look up the process name on > >most platforms, so that code may be shareable. > > > >Git for Windows gathers similar information and logs it as a "data_json" > >event. However, since "data_json" has a variable format, it is difficult to parse effectively in some languages; instead, let's pursue a > >dedicated "cmd_ancestry" event to record information about the ancestry of the current process and a consistent, parseable way. > > > >Git for Windows also gathers information about more than one generation of parent. In Linux further ancestry info can be gathered with > >procfs, but it's unwieldy to do so. In the interest of later moving Git for Windows ancestry logging to the 'cmd_ancestry' event, and in the > >interest of later adding more ancestry to the Linux implementation - or of adding this functionality to other platforms which have an > >easier time walking the process tree - let's make 'cmd_ancestry' accept an array of parentage. > > We are probably going to have to discuss this one at more length. On > NonStop, in some cases, I have access to the program arguments of the > parent (rather like ps -ef) in POSIX-land, but not from the other > personality. I do have access to the program object name, in both > sides, although if someone replaces the object - which is not actually > possible for a running program, but a rename is - the object may end > up being somewhat meaningless or mangled. My suspicion is that I'm > going to have to supply different things for the two personalities, > but I'm not sure what as of yet. I guess I'm having trouble understanding - it sounds like you're describing one process with a graph of ancestry instead of a line. Does that mean we shouldn't be tracing the ancestry the way we are? - Emily
