Add git tracking to rez.ops using ops flag [ops.useGit]

[czuba]

• tracks kilosort repo by default
• [rez.ops.git.kilosort] contains all info to fully recover state of kilosort repo (incl. local changes!) based on any sorted [rez] output data structure
• allows for tracking of additional user repos (e.g. lab-specific kilosort config, data preprocessing/conversion, utilities, etc)
• see ./utils/gitStatus.m for implementation, recovery example, and how to add your own repos

[marius10p]

Thanks, can you please clarify what these two new functions are for: addFigInfo and cmdLog. I don't see them being called inside of this pull request.

[czuba]

Of course,

They're all part of a larger set of revisions in a branch I've been working on that is tailored to sorting spikes from linear array recordings, where some of the dense neuropixel sampling assumptions (sampling from hundreds of sites with ~20µm spacing) have provided less successful results when applied to more modest densities of devices common in NHP recordings (e.g. Plexon Uprobes sampling from tens of sites with 50-100µm spacing).

I wanted to share these more independent git tracking components that might be of general use/interest as a separate commit.

I'm wrapping up work on getting the rest of my revisions tuned up & cleaned up (incl. finally fixing the batch buffer implementation that was causing problems back in v2.0, & significant progress on eliminating persistent batch stuttering issues). ...[always] more work to be done, but I plan to get a fully functional version pushed to my fork in the next couple of days.

---

addFigInfo.m

Makes immediate use of the git revision information by adding important info about the time, codebase state, source, and destination of a given kilosort session to any given figure (as handle input, or gcf).

• useful for things like sort/source information into figures so that they can be meaningfully saved during or after sorting
  • especially important with operations like the datashift2.m method, where the plot is more than just diagnostic, but a visual record of how the source data was manipulated during preprocessing

---

cmdLog.m

Is another step towards standardizing the outputs/updates sent to the command window during sorting.

• accepts a string input, and (optionally) an elapsed time from a toc, appends them in a standardized format (ending the string with a new line char)
• then either prints the output to the command window (no output arguments), or returns it as a formatted string

---