mbox series

[0/2] Randomize / timestamp trace2 targets

Message ID cover.1552519463.git.steadmon@google.com (mailing list archive)
Headers show
Series Randomize / timestamp trace2 targets | expand

Message

Josh Steadmon March 13, 2019, 11:33 p.m. UTC
Persistently enabling trace2 output is difficult because it requires
specifying a full filename. This series teaches tr2_dst_get_trace_fd()
to randomize filenames when a directory or filename prefix are given as
targets in the GIT_TR2_* envvars. It also allows expansion of a
timestamp template string into the current UTC timestamp.

Josh Steadmon (2):
  date: make get_time() public
  trace2: randomize/timestamp trace2 targets

 Documentation/technical/api-trace2.txt | 10 +++
 cache.h                                |  1 +
 date.c                                 |  2 +-
 t/t0210-trace2-normal.sh               | 93 ++++++++++++++++++++++++++
 trace2/tr2_dst.c                       | 86 +++++++++++++++++++++++-
 5 files changed, 189 insertions(+), 3 deletions(-)

Comments

Johannes Schindelin March 14, 2019, 2:34 p.m. UTC | #1
Hi Josh,

On Wed, 13 Mar 2019, Josh Steadmon wrote:

> Persistently enabling trace2 output is difficult because it requires
> specifying a full filename. This series teaches tr2_dst_get_trace_fd()
> to randomize filenames when a directory or filename prefix are given as
> targets in the GIT_TR2_* envvars. It also allows expansion of a
> timestamp template string into the current UTC timestamp.

Given the problem you try to solve, would it not make more sense to use
`getnanotime()` than some randomized file name or an ISO date format?

Ciao,
Johannes
Jeff Hostetler March 15, 2019, 7:18 p.m. UTC | #2
On 3/13/2019 7:33 PM, Josh Steadmon wrote:
> Persistently enabling trace2 output is difficult because it requires
> specifying a full filename. This series teaches tr2_dst_get_trace_fd()
> to randomize filenames when a directory or filename prefix are given as
> targets in the GIT_TR2_* envvars. It also allows expansion of a
> timestamp template string into the current UTC timestamp.


Does the use of envvar cause issues?  Or is it just the fixed absolute
pathname?  When I started this, I was trying to keep the GIT_TRACE
model.

As was briefly discussed in [1] I was thinking of adding a way to
have a personal and/or system setting, but not a git config variable,
that would let you setup tracing without relying on environment
variables.

It's something that I've been wanting to do, it just got buried by
$DAYJOB stuff.  I can try to bump it up if there's interest.

Thanks
Jeff

[1] 
https://public-inbox.org/git/pull.108.v4.git.gitgitgadget@gmail.com/T/#mcce3b088aabc42e9867f8a9e09dd7dea5f9a773a
Josh Steadmon March 15, 2019, 8:37 p.m. UTC | #3
On 2019.03.14 15:34, Johannes Schindelin wrote:
> Hi Josh,
> 
> On Wed, 13 Mar 2019, Josh Steadmon wrote:
> 
> > Persistently enabling trace2 output is difficult because it requires
> > specifying a full filename. This series teaches tr2_dst_get_trace_fd()
> > to randomize filenames when a directory or filename prefix are given as
> > targets in the GIT_TR2_* envvars. It also allows expansion of a
> > timestamp template string into the current UTC timestamp.
> 
> Given the problem you try to solve, would it not make more sense to use
> `getnanotime()` than some randomized file name or an ISO date format?

For my specific use case, getnanotime() would probably be sufficient.
However, others requested the timestamp feature before I sent this to
the list. I don't know whether they had a specific use case in mind.
Josh Steadmon March 15, 2019, 8:38 p.m. UTC | #4
On 2019.03.15 15:18, Jeff Hostetler wrote:
> 
> 
> On 3/13/2019 7:33 PM, Josh Steadmon wrote:
> > Persistently enabling trace2 output is difficult because it requires
> > specifying a full filename. This series teaches tr2_dst_get_trace_fd()
> > to randomize filenames when a directory or filename prefix are given as
> > targets in the GIT_TR2_* envvars. It also allows expansion of a
> > timestamp template string into the current UTC timestamp.
> 
> 
> Does the use of envvar cause issues?  Or is it just the fixed absolute
> pathname?  When I started this, I was trying to keep the GIT_TRACE
> model.
> 
> As was briefly discussed in [1] I was thinking of adding a way to
> have a personal and/or system setting, but not a git config variable,
> that would let you setup tracing without relying on environment
> variables.
> 
> It's something that I've been wanting to do, it just got buried by
> $DAYJOB stuff.  I can try to bump it up if there's interest.
> 
> Thanks
> Jeff
> 
> [1] https://public-inbox.org/git/pull.108.v4.git.gitgitgadget@gmail.com/T/#mcce3b088aabc42e9867f8a9e09dd7dea5f9a773a

Yeah in our case it's the fixed filename that's the issue. It's more
convenient for us to have lots of small files that are "finished"
relatively quickly, rather than one that is constantly appended to.
Jeff Hostetler March 18, 2019, 12:50 p.m. UTC | #5
On 3/15/2019 4:38 PM, Josh Steadmon wrote:
> On 2019.03.15 15:18, Jeff Hostetler wrote:
>>
>>
>> On 3/13/2019 7:33 PM, Josh Steadmon wrote:
>>> Persistently enabling trace2 output is difficult because it requires
>>> specifying a full filename. This series teaches tr2_dst_get_trace_fd()
>>> to randomize filenames when a directory or filename prefix are given as
>>> targets in the GIT_TR2_* envvars. It also allows expansion of a
>>> timestamp template string into the current UTC timestamp.
>>
>>
>> Does the use of envvar cause issues?  Or is it just the fixed absolute
>> pathname?  When I started this, I was trying to keep the GIT_TRACE
>> model.
>>
>> As was briefly discussed in [1] I was thinking of adding a way to
>> have a personal and/or system setting, but not a git config variable,
>> that would let you setup tracing without relying on environment
>> variables.
>>
>> It's something that I've been wanting to do, it just got buried by
>> $DAYJOB stuff.  I can try to bump it up if there's interest.
>>
>> Thanks
>> Jeff
>>
>> [1] https://public-inbox.org/git/pull.108.v4.git.gitgitgadget@gmail.com/T/#mcce3b088aabc42e9867f8a9e09dd7dea5f9a773a
> 
> Yeah in our case it's the fixed filename that's the issue. It's more
> convenient for us to have lots of small files that are "finished"
> relatively quickly, rather than one that is constantly appended to.
> 

Ok. Great.  So if you want to go ahead and do the "if it's a directory
append the last component of the sid" thing, I'll wait for that and
then add the envvar alternative being discussed in another fork of this
thread.

Thanks
Jeff