asv VS git-appraise

> All these workflows are a derivation of the source in the repository and keeping them close together has a great aesthetic.

I agree. Version control is a great enabler, so using it to track "sources" other than just code can be useful. A couple of tools I like to use:

- Artemis, for tracking issues http://www.chriswarbo.net/blog/2017-06-14-artemis.html

- ASV, for tracking benchmark results https://github.com/airspeed-velocity/asv (I use this for non-Python projects via my asv-nix plugin http://www.chriswarbo.net/projects/nixos/asv_benchmarking.ht... )

scikit-image, the project that commissioned this task, uses Airspeed Velocity, or asv, for their benchmark tests.

Problem - The project currently uses Airspeed Velocity for tracking the memory changes. But I am having a lot of trouble setting this up and using this tool for monitoring memory consumption on a regular basis. Are you guys aware of some other open-source tools that I can use instead of this? I am stuck with this thing for some time now. I would appreciate any help.

git-appraise[1] implements that concept. From Google, no less.

I've never used it, or seen it used in the wild, but it always seemed intriguing, and like the obvious approach. The web UI traction is far greater for this to have any serious usage, but I wonder if Git had that ability from the start, if the web UI concept would've taken off as it did.

[1]: https://github.com/google/git-appraise

I believe their docs cover the scenario of reviewing someone's code by pushing your review to the git repo, and others can use `git appraise list` to see open pull requests.

https://github.com/google/git-appraise/blob/master/docs/tuto...

A trivial git-hook could be setup for automating email notifications.

I know about Google’s gerrit. I now found https://github.com/google/git-appraise, there seems to be a plethora on the issue and pr tracking side.

Then the other day there was a generic/abstraction layer to write CI that abstracte over gitlab, circle ci, and GitHub actions (maybe more). I suppose all that’s left is to get some api tokens somewhere and go?

Experimenting with distributed issue trackers in git was popular in the early 2010s, there were a whole bunch of different implementations people came up with for git. Most of them died out though, there were typically a few problems - this is what I remember offhand from experimenting with a whole bunch of them:

* Some of them make a mess of some part of git; one of them put its info in separate git branches to ensure changes were always pushed/pulled even without a special push/pull command for the issue tracker.

* At least one of them kept their info in the repo in a dot-prefixed directory and auto added/committed the file as changes were made; this meant a single issue could be in different statuses depending on which branch you were on and there was no overarching view.

* The rest effectively ran in parallel to the git repo, pushing and pulling their data within it but requiring their own commands to do so, so it was totally possible to clone the repo and not get the issues.

* Most of them didn't have a non-repo way to track issues, for project managers and such. One did have a webview that ran from a repo, but it was up to you to figure out how to keep it in sync with the comments/etc devs were putting in their copies of the issue tracker.

Sibling mentions git-bug, a few others:

https://github.com/aaiyer/bugseverywhere (I think this is one of the original ones)

https://github.com/dspinellis/git-issue

https://github.com/neithernut/git-dit

https://github.com/google/git-appraise (I think this one is newest and I probably never tried it)