FileSystemWatcher + CreateBlob = perpetually dirty loop about gitdiffmargin

[ricksladkey]

You probably want to fix this your own way, but a quick-and-dirty fix can be found in my fork that just watches the .git folder itself and disables subdirectory watching. Watching the entire tree for any changes is overkill because then every rebuild that produces ignored files will make the diff unnecessarily dirty.

[laurentkempe]

@ricksladkey Thanks! I just continued the discussion with @nulltoken on stackoverflow to see if there is another way of doing without triggering the changes to the repository.

[nulltoken]

@laurentkempe Calling ObjectDatabase.CreateBlob() will indeed update the content the .git\objects on the filesystem and there's currently no easy way by default to work around this.

One potential option would be to use a different odb backend dedicated to GitDiffMargin usage and give it a high priority. GitDiffMargin would read/write to this backend by default and fallback to the standard fs backend when an object hasn't been found in the new backend. This new backend could be an in-memory one (beware of the additional memory pressure) or disk based. You can find some guidance in implementing such back-end in libgit2sharp.voron.

Disclaimer: I'm not sure to understand why you need to monitor the changes to the .git folder, so my answer may be quite off. 😬

[laurentkempe]

@nulltoken We need to monitor the folder for changes which would happen out of Visual Studio. For example, commit, stash, change the same file from another editor.. in those cases we want to get the information and update the diff margin. Does libgit2sharp provides events like this to which we could attach?

[nulltoken]

We need to monitor the folder for changes which would happen out of Visual Studio. For example, commit, stash, change the same file from another editor.. in those cases we want to get the information and update the diff margin.

Thanks for the info. Makes sense indeed.

Does libgit2sharp provides events like this to which we could attach?

It doesn't.

/cc @jamill

[laurentkempe]

Thanks @nulltoken then I will go with the solution of @ricksladkey for the moment