git-merge-driver VS nvim-treesitter-context

You could make a custom merge driver for the conflicting file: https://github.com/Praqma/git-merge-driver

I investigated the option of using a custom git merge driver for a project where we were planning to version control a bunch of data files using git.

Here's a proof of concept python merge driver I bashed together at the time to auto-merge JSON objects: https://github.com/fcostin/jsonmerge_git_merge_driver

This never went anywhere near production, but it was very easy to put together something basic.

One complication with using a custom merge driver, as discussed by https://github.com/Praqma/git-merge-driver , is that they need to be configured inside the `.git/config` of the repo, which itself is not version controlled. So there's an additional config management overhead to rolling that out to everyone in a machine. Additionally, if outsourcing hosting for git repos, it may not be supported to install and configure a custom merge driver for merges conducted by the hosting platform (e.g. merges created by github.com pull request workflow).

One idea I had at the time was using external schema files (e.g. JSON schema for JSON files) to help guide/constrain the result of the merge. I never implemented it, but it should be possible. If the schemas were also version controlled in the same git repo that stores the data, you'd need to figure out which one (and which version) to load when resolving a merge conflict of a data file. There doesn't seem to be a well-supported robust way for a merge driver script to discover the source and destination branches, but there are some potentially fragile ways of doing it that work some of the time.

Very cool! Sort of reminds me of treesitter-context. Any chance for compatibility? An example could be you either would disable context when something is pinned or somehow displace it other, depending on which is "on top" could be neat.

It's for context and navigation, not completions. So it wouldn't replace nvim-cmp. It probably doesn't replace anything you already have unless you are already using a winbar. It combines features of treesitter-context, symbols-outline, and a file navigator but in a different presentation.

Not quite the same thing, but arguably a better alternative : https://github.com/nvim-treesitter/nvim-treesitter-context

For 2: https://github.com/nvim-treesitter/nvim-treesitter-context

I really like nvim-treesitter-context as an alternative for 1.

nvim-treesitter-context implements "sticky scroll" where, depending on where your cursor is placed, the top lines of your window will be replaced by the otherwise offscreen lines that declare what function you're in (e.g function test(...), the line that begins the current class (e.g. public class Student implements Person {), the variable name of the current table (e.g. local planets = {), etc.

Very different in my eyes, but I love nvim-treesitter-context. Definitely another tool in helping the brain parse code -- I think of it as helping with long range context, whereas blockman helps me focus on local context and makes scoping relationships more subconciously available.

You are looking for this: https://github.com/nvim-treesitter/nvim-treesitter-context

I have seen https://github.com/nvim-treesitter/nvim-treesitter-context is recommended, and it works similar. But the way the context info are displayed in AstroNvim is much nicer