Search and insert the right issue at “Fixes #”

Goal: In a magit commit buffer, I want to complete the issue when I type “Fixes #”.

This actaully works with any other keyword supported by Github:

close closes closed fix fixes fixed resolve resolves resolved

Gitlab and Bitbucket understand more keywords, but actually a sharpsign # alone is enough for them to reference and link back to an issue. However, fetching the list of issues is triggered by a keyword followed by a sharpsign, and not # alone. We recognize also these keywords:

for see reopen hold wontfix invalidate re ref refs addresses

and the s and ing variants: invalidates, invalidating etc.

This works with individual projects (repo of type username/projectname), groups (groupname/projectname) and forks (where the issues are on the original repo).

Bitbucket: works with private projects. Install bitbucket.el (in melpa).

If you have more than one remote in your project’s .git/config, read below.

Usage

Activate the minor mode

M-x git-commit-insert-issue-mode

Then, in a magit commit buffer (git-commit-mode), type “Fixes #” (or use another keyword) and choose the issue from the list.

To always activate the mode:

(add-hook 'git-commit-mode-hook 'git-commit-insert-issue-mode)

You can also call it with

M-x git-commit-insert-issue-ask-issues

and you can call it programmatically:

(--map (insert (concat it "\n"))
       (git-commit-insert-issue-github-issues-format "inkel" "github-issues.el"))

Connect to your Bitbucket account

See its README, but shortly it boils down to

(setq bitbucket-basic-auth "my-basic-auth-token")

or

export BITBUCKET_BASIC_AUTH=my-basic-auth-token

Working with many remotes (and one issues source)

The first remote in your .git/config will be the one we get the issues from.

A project may have many remote git urls: the upstream one on Github, your fork and a copy on Gitlab, or maybe the original one in a self-hosted Gitlab instance and a mirror on Github. Where are the issues then? Git itself can not tell us, so we decide we’ll go with the first remote url in your .git/config. Just edit this file manually to set it right.

Example:

In this example, we infer that the foobar remote is the one that holds the issues, so we’ll try an API call to foo.com, assuming it is Gitlab. That fails (you see a nice error message).

   # .git/config
   [remote "foobar"]
	url = git@foo.com:a-private-remote/project.git
	fetch = +refs/heads/*:refs/remotes/origin/*
   [remote "origin"]
	url = git@gitlab.com:emacs-stuff/git-commit-insert-issue.git
	fetch = +refs/heads/*:refs/remotes/origin/*

You should put origin first:

   # .git/config
   [remote "origin"]
	url = git@gitlab.com:emacs-stuff/git-commit-insert-issue.git
	fetch = +refs/heads/*:refs/remotes/origin/*
   [remote "foobar"]
	url = git@foo.com:a-private-remote/project.git
	fetch = +refs/heads/*:refs/remotes/origin/*

We can maybe do better, discuss on #12.

Plug with ido (ivy or helm work out of the box)

The code uses the default completing-read function to interactively ask for the issue. If ivy or helm are activated, they will pick it up and you have nothing to do.

However ido-mode doesn’t (strangely). So we can set the completing-read function to use it:

(setf git-commit-insert-issue--completing-fun #'ido-completing-read)

Installation

This package is in MELPA, so you can install it with package.el:

M-x package-install RET git-commit-insert-issue RET

(you may need a M-x package-refresh-contents).

Alternatively, you can download this repo and call M-x load-file on the elisp source.

Dependencies

• ghub (which also provides glab and is for Emacs 25+)
• projectile
• s.el

They are all in MELPA.

Issues

• if you play too much with it, you can reach github’s rate limit.

Issues for github integration of github-issues.el :

(--map (insert (concat it "\n")) (git-commit-insert-issue-github-issues-format "inkel" "github-issues.el"))
#10 - Why not just use the gh package?
#1 - Doesn't work on private repos.

Todo

• [ ] tests
• [ ] cache
• [X] gitlab integration:
  • [X] Get opened issues from gitlab
  • [X] Get a list of strings with “id - title”
  • [X] choose with ido and insert in buffer: M-x git-commit-insert-issue-gitlab-insert.
  • [X] choose github or gitlab, depending on project.
    • [X] get the remote server in git config
  • [X] make it work for projects in groups (i.e, “emacs-stuff/project” and not “vindarel”.
    • [X] get the group name in git config
  • [±] error handling (bad project name, etc)

Ko-fi & Liberapay

You use this daily ? You feel like pushing me to un-rot the code ? You can offer me a beer :]

https://liberapay.com/vindarel/

https://ko-fi.com/vindarel

Thank you <3

(why? I’m working towards independance with free software projects now so I must practice in asking for support…)

Changelog

v0.4 (December, 2020)

• replaced deprecated github-issues by ghub. That makes Emacs 25+ a requirement.
• fixed Gitlab for public repositories.
• fix when parsing the first remote fails, add an explicit error message.

v0.3.2

• added the variable git-commit-insert-issue--completing-fun, so we can set it to ido-completing-read. Ivy and Helm work out of the box. <2020-10-08 Thu>
• remove the harcoded ido-completing-read and make room for ivy. <2017-11-01 mer.>

v0.3 <2017-04-24 lun.>

• Add Bitbucket support (Tjaart van der Walt)

v0.2

• Gitlab support: private and public, individual, groups or forks. We then consider the project url and username of the first remote to appear in the user’s .git/config.
• ido (with \n) instead of helm
• auto gitlab login
• more error handling
• github-issues dependency in melpa

v0.1 - release on Melpa

• Github only