Unexpected git hook behaviour with ~/.git_template/hooks

[deas]

Hi,

I have hook files in ~/.git_template/hooks and I am seeing unexpected behaviour.

The first thing is that those files get soft linked from <project_root>/.git/hooks when you clone a repo. Hence, when you call vectorcode init --hooks, this introduces the vectorcode bits "globally".

Cloning a repo is a special case where the old SHA has a special value which does not work with git diff:

bad object 0000000000000000000000000000000000000000

Hence, I saw this error on every new clone once I had introduced the hooks.

The second thing is that I did not want the vectorcode bits on every repo.

Long story short:

I changed the fragment to:

# VECTORCODE_HOOK_START
if [ -d ".vectorcode" ]; then
  if [ "$1" -ne 0 ]; then
    files=$(git diff --name-only "$1" "$2")
    [ -z "$files" ] || vectorcode vectorise $files
  else
    vectorcode vectorise
  fi
fi
# VECTORCODE_HOOK_END

Not quite sure, but those may be slightly better defaults?

[Davidyz]

Yes, that's a good catch. I'll fix this.

On a separate note, do you think it makes sense to throw a warning on symlinked hooks?

[deas]

Issuing a warning or asking for explicit confirmation surely makes sense when potentially introducing "global" behaviour.

BTW: Slightly changed the fragment above. I think the defaults we might want is:

"If there is a directory .vectorcode, we want all the magic automated"

I think that condition should never hurt. Not quite sure about "all the magic", though. ;)

Also not sure if we want or need additional treatment on checkout. Does current behaviour honor file removal properly? Would that remove things from the collection?

[Davidyz]

Issuing a warning or asking for explicit confirmation surely makes sense when potentially introducing "global" behaviour.

On second thought, it might be better if we just abort the modifications to the hook when the hook is a symlink? Because if it's a symlink, it's probably managed by something else, and there's really no silver bullet that will make everything happy. If users are using things like git_template, it'll be easy to set up the hooks anyway (using the snippet you provided).

Does current behaviour honor file removal properly? Would that remove things from the collection?

Whenever you run vectorise or update from the CLI, VectorCode removes orphaned chunks from the database (that is, chunks that belong to files that no longer exist). This keeps the information in the database up-to-date. I just noticed that the vectorise features in the new LSP and MCP don't respect this, though. I'll patch them too before 0.7.0.

[deas]

On second thought, it might be better if we just abort the modifications to the hook when the hook is a symlink? Because if it's a symlink, it's probably managed by something else, and there's really no silver bullet that will make everything happy. If users are using things like git_template, it'll be easy to set up the hooks anyway (using the snippet you provided).

Vectorcode only manages the fragment between the markers and should know best what "all the magic automated" is, no?

Hence, I'd say it would be convenient if it takes care of it - also with regards to potential future changes in that bit. It can always bail out telling the user to take over. Also, I think the pattern of taking care of a configuration (file) fragment is not uncommon.