neithernut / git-dit Goto Github PK

What the title says.

What the title says. Porcelain commands should go into the binary.

is it possible to add other metadata keys than the ones are listes in the helppage?

git-dit new --metadata YetAnotherKey=myValue

I would really like to define keys using a config file.
When inserting a new KV-pair the keys defined there should be respected.

What the title says. Porcelain commands should go into the binary.

The ordering of subcommands should be consistent between

• src/cli.yaml
• the implementations in src/main.rs
• the match in the main() function in src/main.rs

The porcelain commands should be separated from the plumbing commands, e.g. plumbing first, then porcelain.

Should be done before any of #37, #38, #41, #50, #51, #52 and #53, IMO

At least not with push.

We should add travis-ci.

What the title says.

Together with the head refs of an issue, we can use the leaf references of an issue for showing an issue and garbage collection of unnecessary leaves.

git-dit was written to replace systems storing issues in an opaque web application. Storing issues in a repository allows communicating them between different (git-based) platforms. Hence, you might wonder why this repo has "issues" enabled.
We do not yet have a viable mechanism for notifying maintainers about changes to issues. Originally, we had mailing lists in mind, but we also planned on creating web-based protocols for general purpose notification mechanism for repo updates (also usable for CI and other stuff), at some point (in another project). However, as long as users do not like to send (partially hand-crafted) emails to us but rely on a web-interface and as long as the aforementioned tools do not exist, we are stuck with github-issues.

We will disable issues on this repo, once git-dit has overcome the PoC-stage and we can, in some way, be notified about contributors' issues.

For some of the functionality we want to provide we need to trace commits back to an issue's initial message via the chain of commits' first-parents. An iterator which follows the first parents would be advantageous.
The iterator should be constructible from a git2::Commit, return the commit itself on the first call to next() and return the first-parent of the last commit returned in subsequent calls.

The new and reply subcommands will spawn an editor. We should add a function doing this, honouring the git-config. The function should resort to the EDITOR variable, if the config doesn't specify an editor.

This partially targets #17, albeit the issue will only be resolved when both new and reply are ported to rust.

It would be great if the various distributed issue trackers could agree on a simple file-based tree of issues and comments the way git-dit and BE have. I think the BE file structure was particularly well thought-out and can provide you with a copy of the Python code if you're interested.

We need some infrastructure for calling the sub-command internally. If a sub-command is not implemented in the binary, if should try to invoke a binary with a matching name.
Blocks #10 and #11.

As far as I can see, none of our versions (neither 0.2.0 nor 0.2.1) is released: https://crates.io/search?q=git-dit

What the title says. We currently have almost no real error, just "TODO"-error kinds.

The Makefile is no longer used.

We should really ensure everything is documented (#![deny(missing_docs)]), even better would be:

#![deny(
    non_camel_case_types,
    non_snake_case,
    path_statements,
    trivial_numeric_casts,
    unstable_features,
    unused_allocation,
    unused_import_braces,
    unused_imports,
    unused_mut,
    unused_qualifications,
    while_true,
)]

before releasing.

(More) details on the data storage should go into the readme and manpage.

We already wrote some docs about our data storage as part of a project documentation, which we handed over to our university. It wouldn't be much work extracting the relevant parts. Maybe we should have done this before people on the internet asked about it/read things up in the source code.

https://github.com/google/git-appraise

Maybe relevant, seems to have a different goal.

Add a function or function family to our RepositoryExt returning issue hashes (e.g. as an iterator of git2::Oids). It should be possible to retrieve the hashes for a given set of remotes and/or the local repository.
Then add an implementation of the get-issue-tree-init-hashes subcommand to the binary.

Discussion issue for binary attachements.

Two options which I currently see here:

• git-annex, which is an awesome tool and fits perfectly well for the job, but has the one disadvantage that it uses symlinks (so in-tree "files") for referencing content
• ipfs, which is wonderful and works great, but then binary content is not tied to the repository. This means that binary blobs can be dropped (and would be lost then) without modifying the repository at all. I'm not sure whether we want such a thing. With IPLD, though, we could still refer from the content to the issue (more accurately: To a hash) it belongs to. So that's not a problem.

Of course this is not a thing which might be solved tomorrow, but I'd like to open this anyways to keep track of ideas.

I am currently in the process of writing an app with libgitdit and I found that it is way to hard to use.

For example, for checking whether an issue is "open", this code has to be written:

pub fn issue_is_open<'a>(i: &Issue<'a>) -> Result<bool> {
    use libgitdit::trailer::accumulation;
    use libgitdit::trailer::accumulation::Accumulator;
    use libgitdit::trailer::TrailerValue;
    use libgitdit::Message;

    let policy  = accumulation::AccumulationPolicy::Latest;
    let mut acc = accumulation::SingleAccumulator::new("Dit-status".to_owned(), policy);

    let mut messages = vec![];
    for message in i.messages()? {
        let mut trailers = message?.trailers().collect();
        messages.append(&mut trailers);
    }

    acc.process_all(messages.into_iter());

    if let Some((_, val)) = acc.into_iter().next() {
        match val {
            TrailerValue::String(s) => s == "OPEN" || s == "open" || s == "Open",
            _ => false,
        };
    }

    return Ok(false);
}

(The actual check for "open", "OPEN" and "Open" is trivial, but the aggregating of trailers is way too complex).

Of course, this functionality should be part of libgitdit as in Issue.get_latest_trailer("Dit-status")? == "Open" for example, but that's another problem.

The boilerplate for writing this code is way to much. This is only one example, there are other places where this library is too complex to use.

If we want to port tools to rust, we obviously need to set up a build environment. A build should pull in git2 and produce a "git-dit"-library, which will at some point feature basic functionality used in the one-shot commands.
Blocks #10.

Device on a representation of trailers (as key-value pairs). Simple tuples might suffice.
Add a facility for extracting them from a stream (e.g. iterator of chars). This may be a function to RepositoryExt or (more fancy) a iterator-adapter. Implement extract-trailers based on the function.

Up until now, we neglected automated testing. All we did was manually smoke-testing new functionality.
To reduce the probability of errors leaking through, we should definitely make use of automated testing, including tests using on-the-fly repos.
Obviously, the library and library-internal modules should be the primary target for testing. However, it was suggested having some smoke-tests on the binary, in order to prevent unintentionally breaking the user interface.

$  ./target/debug/git-dit list
IO Error
No such file or directory (os error 2)

$ ./target/debug/git-dit show 47762849e251495d701112a8290f0ba56e433b78
IO Error
No such file or directory (os error 2)

can you reproduce?

Add a function to RepositoryExt for extracting all metadata (or a defined subset) for an issue. Implement the subcommand based on that function.

IMO git dit list should show author date rather than committer date.

What the title says. Porcelain commands should go in the binary.

When listing a huge thread/tree with show -g, it would be awesome to have colors to quickly see where what is located.

Other commands might benefit as well from a bit of color.

Not that important in 0.y.z development, though necessary for a nice 1.0.0!

https://github.com/2hdddg/pug

What the title says.

First, if $EDITOR is not defined, it won't work:

root@journaldev:/opt/git-dit# git dit new
git: 'interpret-trailers' is not a git command. See 'git --help'.
/opt/git-dit/git-dit-new: line 123: /opt/git-dit/.git/COMMIT_EDITMSG: Permission denied
The format of the provided message is faulty
root@journaldev:/opt/git-dit#

Second, if $EDITOR is available, it hangs:

root@journaldev:/opt/git-dit# git dit new
git: 'interpret-trailers' is not a git command. See 'git --help'.
[dit][new]: f5b67c4b9ce06d5930dd929200d4e31018486ddc
root@journaldev:/opt/git-dit# git dit push origin
error: unknown option `contains'
usage: git for-each-ref [options] []

-s, --shell           quote placeholders suitably for shells
-p, --perl            quote placeholders suitably for perl
--python              quote placeholders suitably for python
--tcl                 quote placeholders suitably for tcl

--count <n>           show only <n> matched refs
--format <format>     format to use for the output
--sort <key>          field name to sort on

error: unknown option `contains'
usage: git for-each-ref [options] []

-s, --shell           quote placeholders suitably for shells
-p, --perl            quote placeholders suitably for perl
--python              quote placeholders suitably for python
--tcl                 quote placeholders suitably for tcl

--count <n>           show only <n> matched refs
--format <format>     format to use for the output
--sort <key>          field name to sort on

Everything up-to-date
root@journaldev:/opt/git-dit#

Someone on reddit said that we need workflow examples. Probably in the README file.

Some commands will spawn a pager. We should have a function doing this. Like with the editor (#33), the function should honour the git-config. Blocks #41 and #51.

It makes sense to rename the editor module to programs or something similar, then add the pager functionality.

Right now we lack a way to git dit show -t all issues, am I right?

Or even list all issues with -g (one might want that...)

What the title says.

Please add your project to the Distributed Bug Tracking Systems Wiki at https://dist-bugs.branchable.com/.

Maybe also announce it at https://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs respectively [email protected].

TIA!

When creating a new issue, all metadata-keys are prefixed with Dit- this behaviour is not described in the helppage.

Right now we have a "todo"-error kind, which is used for wrapping. Before we release we need to introduce actual error kinds.

I'm not entirely sure what is left to do.

I would go on merge the PRs which are in the queue:

• #101
• #104
• #105
• #106
• #109

After these are merged, we should smoke-test all the things and then get the release out.

I'm pretty sure that we can get out the release within the next two weeks, what do you think?

Stripping white space from the end of lines (e.g. #42) is insufficient. We also need to strip commentary lines (e.g. lines starting with the #) character and all empty lines until the first non-commentary line.
All of this could, again, be performed using (existing) iterators.

What the title says. For this, a function may be introduced to the library for checking the message format.

We should use the git config variable instead, and resort to using the environment variable only if the config does not provide an editor. Maybe we also should die with an error message if we cannot find an editor.

This will most likely be fixed during the re-write. However, it may as well be fixed in PoC. It is an obvious problem with an easy fix.

What the title says.

Add a function implementing the search. Then add a program calling that function, replacing the existing sub-command.
Blocks #11.

This may be combined with #26.

A flag for not piping to pager is missing.

Also: If the terminal is wide/high enough, we shouldn't pipe to the pager at all (or provide a flag to enforce it).

There are two possible solutions:

• make cargo build the existing man page (git-dit.1.md)
• build a man page from the clap CLI spec

Blocks #93.