musicmatze

I use systemd mainly as a user, only on one of my instances I do some more "admin" like stuff. It works and is absolutely reliable for what I do and did by now. I couldn't imagine going to something else and would also see no reason why I should.

     1  401  16.04%  git
     2  337  13.48%  fg
     3  241  9.64%   cargo
     4  234  9.36%   cd
     5  197  7.88%   ls
     6  195  7.8%    tig
     7  165  6.6%    task
     8  81   3.24%   vim
     9  38   1.52%   imag
    10  31   1.24%   pwd

"imag" is my own tool, a personal information management suite for the commandline.

Would love it!

OP please open-source it!

Reposting this (https://news.ycombinator.com/item?id=16124702) as top-level comment, because I think it is worth it:

The git-dit project (https://github.com/neithernut/git-dit) provides a distributed issue tracking functionality inside git.

It does this without cluttering the repository with unneeded files, gives the possibility for having tree-like conversation (including merging conversations), referencing issues, linking to commits and so on. It is even possible to host the issues in another repository as the code (if that is wanted) or having one repository of issues for several projects / moving issues from one repository to another.

There is only a CLI as of today. I hear that there is some effort on building a (view-only) web frontend for it, though I don't know much about its progress. Maybe asking the maintainer would be an idea.

What's also missing is a way to give users of the tool access to a repository where they can submit issues (which then could also be used by a web/gui frontend for the tool). This is not the domain of git-dit itself, but a solution needs to be found. One idea would be a publish repo (where everyone can push) which automatically does some sanity-verification on the issues and forwards them to the maintainers repository... or something like that. Also integration/mappers to/from other services (gitlab, github) are missing and so is mail->git-dit integration (posting issues from a mailinglist automagically into the issues repository).

Also, https://github.com/vitiral/artifact/ is a really nice tool to do planning of an application or library inside a git repository. I am currently starting using it in imag (https://imag-pim.org) and it is really wonderful. The author currently does a reimplementation of its core functionality to make it even more powerful.

https://github.com/neithernut/git-dit provides a distributed issue tracker inside git, without cluttering the repository with unneeded files and also gives the possibility for having tree-like conversation, referencing issues and so on.

Unfortunately, no non-cli frontend exists right now (feel free to build one, shouldn't be complicated). Also some convenience is still missing, but could easily be integrated.

What's also missing is a way to give users of the tool access to a repository where they can submit issues (which then could also be used by a web/gui frontend for the tool). This is not the domain of git-dit itself, but a solution needs to be found. One idea would be a publish repo (where everyone can push) which automatically does some sanity-verification on the issues and forwards them to the maintainers repository... or something like that.

Also, https://github.com/vitiral/artifact/ is a really nice tool to do planning of an application or library inside a git repository. I am currently starting using it in iamg (https://imag-pim.org) and it is really wonderful. The author currently does a reimplementation of its core functionality to make it even more powerful.

Awesome, thanks for your feedback! Yes, we did consider C++ as well, but IMHO the tooling is better with Rust and we are both familiar with it, so that seems to be the better choice.

Hi. Awesome you want to contribute! Well, take part in discussions in the github issues (which should be transferable at some point and therefor also show up in git-dit), would be the first step. We now have to sort out what our next steps are...

Hi. As angrow has written, yes, patches/patchmails would be an option. We did this explicitly leaving out the access-control problem, which is a hard problem by itself.

Currently we would think of emails as first step, which clearly would make it harder for newbies, true. We also thought about other possible workflows but in the end a project needs some people accepting issues. This could be automated with git-dit of course - something like `git dit fetch-issues --from repo@repohost` which then asks the maintainer for each new issues to review and accept or reject it with a single keystroke. Either way, we currently see no way around that problem.

Hi. Due to the nature of git, this is not possible after the issue is distributed to the network, hence there is no possibility to implement such a thing.

Hi. Thanks for your reply. We already thought of that, and we concluded that it would be a great idea to make it configurable whether the current repository (the `pwd`) should be used for issue storage or another git repository. So one can have one repo for code and another for issues, giving them the possibility to transfer issues from the issue-repo to the code repo, if desired.

Co-Author here.

git-dit is a distributed issue tracker in/for git, currently implemented as proof-of-concept in Bash. If you want to play with it, make sure you use current git versions.

It differs from things like bugseverywhere and fossil in that it is a distributed issue tracker for git only, using git features to implement issue tracking in a way so that merging of issues, attaching issues to commits, creating PRs, etc is possible. It does explicitely _not_ store any "structured data" like JSON, YAML or such, but simply uses git commit messages for issue messages. So, E-Mail workflows, github, gitlab and other hosting platforms and their issue tracking schema can be adapted and mirrored into "git-dit", technically. We are not there yet, though. We are planning to reimplement the current featureset in a more robust language.

When playing with this, please keep in mind that this is a POC - there are bugs, missing things and rough edges. Do not use on a production repository!

I'd happily answer your questions!

Well, from what we've experienced during the implementation and while using our tool, it works _really_ well!

I just checked git-appraise and while it looks rather mature, it uses (as far as I can see by now) an approach which is not that nice if you have multiple public remotes. Also, as far as I can see, each submitter must be able to push to that remote - please correct me if I'm wrong.

We have a different approach for this, which is more powerful (talking about how the data is stored).

Of course, our tool is not mature yet. Maybe gitlab can learn from what we've researched...

They say that git data (repos and wikis) are not affected... well ... if they would have had their PRs and Issues in git repositories, too...

Disclaimer: Worked on a POC for exactly this last semester and going to publish my results in the next few weeks.

I am developing a CLI-PIM suite (commandline personal information management suite) called imag[1].

The goal of the tool is to use known commandline tools (for example taskwarrior (todo), khal (icalendar), khard (vcard), beancount (financial data), mutt (Maildir actually) and so on) and give the user the possibility to (semantically) connect the data of these tools. Then, one can do data mining on PIM data.

imag[1] is in pre-alpha shape and only few things are there by now. 3 days ago I released version 0.2.0 with tools (we call them "modules") for the following "pim aspects": bookmark, counter (this was a first example module), diary, link (to semantically link data), notes, ref (to refer to files outside of the "imag store"), store (to do plumbing in the "imag store"), tag (to add tags to data), todo (basic integration for taskwarrior) and view (to view entries from the "imag store").

As said, we are in a really early stage of development and only few things are there yet. This is a hobby project I'm working on in my free time (also to learn Rust) and I only can make progress if I have enough time to do things.

I also write blog[2] articles about imag every two weeks about what's currently going on in the codebase. Read about a use-case I'm thinking about in one of my blog posts[3] - and yes, these are really ambitious goals!

Feel free to ask questions!

Edit: Fixed link markup. Sorry about that.

[1]: https://github.com/matthiasbeyer/imag [2]: http://beyermatthias.de/tags/imag.html [3]: http://beyermatthias.de/blog/2016/08/07/imag-usecases/

What I really wonder right now: When reviewing my own PR on my own repo, I cannot select that the things I proposed must be resolved before the PR can be merged - why is that? Am I not allowed to keep myself from merging things I considered changeworthy or what?

Is there a way to make this work with `set -o vi`? So I can use j/k to browse the history this way?

Absolutely. I'm using it for two or years or something by now and the very first thing I do when having a new host: install the mosh server.

This looks really interesting. I've been thinking about the problem of distributed issue tracking lately... and the set of sub-problems it has (authorization and authentification, synchronization and so on) ... I'm not sure all these problems could be covered by this, but I guess at least the "distributed"-part could be covered by something like this.