Git Hooks example?

[doronbehar]

Hey there:)

So, in my projects' developments, I use Direnv (.envrc) and a Nix flake setup. Direnv watches the flake.{nix,lock} files which change pretty often through out my development, and also when I switch branches etc. Whenever the modification time of flake.{nix,lock} changes, it triggers a Nix evaluation of the devShell attribute, and this can take time.

Sometimes, when I perform a big rebase, in which easily cherry-picks a commit that modified flake.{nix,lock} ('easily' means without merge conflicts), there is no point in Nix evaluating again the devShell.

I was wondering, do you think git-warp-time could be utilized to spare that evaluation via Git Hooks?

Disclaimer: I haven't tried to sketch such a hook myself, and it is not super critical for me (I can live with the now slow evaluation in the rare cases in which I rebase). Also, I imagine it may be very simple to setup this hook, but I want to know what would you think of the idea first, and perhaps you'd like to document that usage in the README :).

[alerque]

I was wondering, do you think git-warp-time could be utilized to spare that evaluation via Git Hooks?

Yes, with two three caveats:

1. It also sounds like you might have a problem with race conditions. You say direnv is "watching" the files. If it is doing that with an io event callback you're going to have a problem "fixing" the timestamp before it runs. There would need to be some sort of debounce function such as a delay with a recheck of the conditions or something like that ... or triggered directly by you after git-warp-time. How does direnv behave itself during a rebase when you are resolving conficts?

2. This assumes direnv is evaluating the file's final timestamp. Given what you are saying in looking into this at all I assume it is timestamp based, not hash based. Also related to caveat №1, if the trigger is not "is this file newer" but instead "did the filesystem say this file got written to" then the answer is going to be no. By the same token if the trigger is the timestam and you get around the race condition problem, then you have to ask yourself whether cherry picking two commits in topological order might not actually lead you to a false-negative situation where the timestamp is older than the actual modification. Just because a cherry pick applied cleanly doesn't mean the later commit timestamp reflects the last time the it was modified if you modified commits in the further past.

3. I forgot what the third one was going to be ... hmmm ... oh yah ... git rebase and git cherry pick in particular can leave some interesting artifacts in history that git-warp-time does not currently account for. I should probably open an issue for adding a more aggressive history scan mode, but the way it currently works it walks the history from the HEAD down looking for the first commit in topological order that touches a file. If commits are applied out of chronological order this can easily lead to the final timestamp being older than some previous commit that touched the file.