On Mon, Aug 26, 2019 at 9:28 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jeff King <peff@xxxxxxxx> writes: > > > I was thinking that Git itself could treat "ttl=0" specially, the same > > as your nocache, and avoid passing it along to any helpers during the > > approve stage. That would make it exactly equivalent to your patch > > (modulo the name change). > > ... > > And as you noted above, if we don't suppress the helper calls inside > > Git, then every matching storage helper needs to learn about "nocache" > > (or "ttl") before it will do any good. > > I was waiting for this discussion to settle and then the discussion > seems to have petered out. Any interest to following the "ttl with > special casing value 0 as 'nocache'" idea thru from either two of > you, or should I take the patch as is in the meantime? Sorry for the late reply. I think about this again. I imagine that, if I would like to have credentials with an expiration and I want to have them managed by other helpers, it's probably better to use an absolute timestamp instead of duration. The second call to the helpers is done after the remote call. For the helpers that store TTL-ed credentials, they cannot tell the start time of the TTL in the second call. This makes it hard to cache the short-lived credentials safely because some time has spent during the remote call and the actual TTL is shorter than ttl=N option. From this, instead of adding ttl=DURATION, it might be better to have expires_at=TIMESTAMP. Maybe my observation is not an issue. I don't know. For now, adding nocache seems a safer action for me, so I vote for taking nocache patch as-is in the meantime. If there's somebody who wants to receive TTL or expiration timestamp, they can decide what's actually needed later.
