Remember all previously verified configurations

[deivid-rodriguez]

I can't rebase to past revisions with different overcommit configurations. I end up in a detached state. I tried disabling signature verification but it will only work for commits after disabling the check.

This behavior is weird since I've already acknowledged all past revisions of overcommit's config, so I shouldn't need to verify them again. The only solution I've found it to completely uninstall overcommit hooks just for the rebase.

Let me know if you need more information.

Thanks!

[trotzig]

Echoing what @sds informed me about when I ran into the same issue:

Because of the nature of the latest overcommit version, you needed to pull/rebase with OVERCOMMIT_DISABLE=1.

So something like

OVERCOMMIT_DISABLE=1 git pull origin master

[deivid-rodriguez]

@trotzig @sds Thanks to both for that. It's certainly more convenient than the workaround I ended up using:

bundle exec overcommit --uninstall
git rebase ...
bundle exec overcommit --install

I still think this is undesirable and shouldn't be necessary but if the fix is difficult to implement, I find the workaround acceptable.

[sds]

You raise a good point, @deivid-rodriguez. It would be nice if Overcommit remembered all previously-signed configurations.

[gerrywastaken]

@sds also even if it hasn't remembered previous states, it probably shouldn't end up leaving the branch in a detached state with no obvious way to recover or continue the rebase after signing.

[ryanclark2]

Is this still alive? Ran into this today after making changes to overcommit.yml then rebasing a branch onto master.

[benbernard]

would really like this to land. Assume you folks would accept a pull request? Any pointers for where to start with the signatures?

[sds]

Would love a PR addressing this, @benbernard!

You'll need to modify the HookSigner class to support searching through a list of previously-verified signatures.

This may involve creating a different storage format for the configuration value so that a quick lookup can be performed (emphasis on quick—the list of signatures will potentially grow quite large with time, so this needs to be something supporting a constant-time lookup).

Hope that helps!

[benbernard]

@sds are you suggesting better than O(fileSize) like you want to do a search on disk? That seems like overkill. If we are going to read the whole file into memory to load it into a hash (like with a protobuf or a json file) it seems like that will get an O(fileSize) step, and so an addition single O(fileSize) search for an exact match in the set of strings won't actually take a long time.

Seems like signatures will grow at a rate O(number of .overcommit or custom .githooks) changes, that doesn't seem prohibitively large. Something simple like a SHA/signature per line seems like it would be reasonable?

I'm just trying to answer some questions on approach before I dive in :) Thanks for the assist!

[benbernard]

I could also keep the most recent signature on "top" of the file and probably keep O() costs the same if the signature exists and is the most recent signature (the happy case) and only incur O(fileSize) search when there is no immediate match