Git Rev News: Edition 43 (September 19th, 2018)

Welcome to the 43rd edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.

This edition covers what happened during the month of August 2018.

Discussions

General

  • Google Summer of Code 2018 wrap up

    The three students who worked on projects to improve Git this summer as part of Google Summer of Code 2018 have successfully passed their final evaluation.

    They have created repositories with a lot of information related to their work:

    Their patch series are still not fully merged, but it seems that this is likely to happen after perhaps a few more review and improvement cycles.

    Fast, built-in versions of git stash and git rebase based on their work are already available as experimental options in Git for Windows 2.19.0.

    Congratulations to them and their mentors!

  • git-bug: Distributed bug tracker embedded in git

    Michael Muré emailed the mailing list to announce that he had just released “git-bug, a distributed bug tracker that embeds in git”.

    Michael had previously announced it on Hacker News where Ævar Arnfjörð Bjarmason suggested him to also post on the mailing list.

    Michael described his tool like this:

    It uses git’s internal storage to store bugs information in a way that can be merged without conflict. You can push/pull to the normal git remote you are already using to interact with other people. Normal code and bugs are completely separated and no files are added in the regular branches.

    and:

    It’s an all-in-one binary that is picked up by git as a porcelain command. It features a set of CLI command for simple interaction, an interactive terminal UI and a rich web UI.

    He also gave a link to the documentation of the internal design.

    Jonathan Nieder replied to Michael asking if it might be possible to rename the tool to use a less generic name, as Jonathan envisioned “a future Git command like git bug to produce a bug report with appropriate diagnostics for a bug in Git”.

    Ævar replied to Jonathan suggesting other names for the envisioned command to report bugs in Git, and starting a subthread about adopting a policy regarding external tools named “git-whatever”.

    This subthread involved Ævar, Jonathan and towards the end Jeff King, alias Peff. It looks like the Git community is likely to continue to recommend against too generic names. Peff gave the example of the Microsoft GVFS tool which is in a similar situation, as people are thinking about using the git-vfs command name which Peff also considers too generic.

    Tacitus Aedifex also replied to Michael saying that he had “often wanted an integrated bug database like this”, and that he had created his own solution for this purpose using a “subrepo storing bug reports and comments in .txt files” and “bash porcelain scripts”.

    Junio Hamano, the Git maintainer, replied to Michael, too. He told that this reminds him of a “demo Scott Chacon showed us ages ago”.

    Jonathan added that the tool Scott demoed was TicGit. Then Jonathan started along with Kyle Meyer to compile the following lists of similar tools and links related to them in a small subthread:


    Jonathan commented that it was nice to see new work in this area as “it seems to have gone mostly quiet since 2014”. He also added git-dit authors in CC of his last email in the subthread, while saying that git-dit seems to have “very similar goals and a similar data model” as git-bug, and suggesting that the authors could work “more closely together”.

    This later prompted Julian Ganz, a co-author of git-dit, to request comments in an email called “[RFC] Git enumerations” about a functionality which he had originally planned on introducing it as a git-dit internal feature. Unfortunately, it looks like no one commented on the proposed feature.

    Jonathan also sent another reply to Michael’s original email. Commenting on the documentation of the internal design of git-bug, he said that he likes that git-bug uses the hash of the first commit in the chain of related commits as identifier for the bug.

    About the fact that Git doesn’t provide a low-level command to rebase a branch onto another without touching the index, Jonathan replied that a lot of related work has been done lately, as merge code (also used for cherry-pick) is less reliant on the index and worktree, and rebase code is being ported to C (see the article about Google Summer of Code 2018 above). Jonathan suggested setting the GIT_INDEX environment variable to point to a temporary index file as a work-around until something like git cherry-pick --onto=<branch> <revisions> is implemented.

    Jonathan then asked about which federation model git-bug intends to support. Michael replied giving technical details about how the tool works and saying:

    So for now, collaboration is based on push/pull to whatever remote you want, as git does, with the exception of the Web UI. The goal here is to have it running locally for each user but also to make it a public interface for users that don’t have write access to the repo, much like any bug tracker has.

    and:

    In the future, it could be possible to have more fancy features like a federated forge with ActivityPub, but that’s way outside of the scope of the project for now.

    About Jonathan’s suggestion for an --onto option in git cherry-pick, Elijah Newren replied that, after his current work on the merge code, he indeed wanted to work on that, and also investigate “in-memory” merges to improve interactive rebase performance. He agreed that “we’re pretty close to having a rebase-without-touching-index-or-worktree that we can make accessible to other scripts like git-bug”.

Releases

Other News

Various

Light reading

Git tools and sites

  • bat, a cat(1) clone with syntax highlighting and Git integration
  • Lerna is a tool that optimizes the workflow around managing multi-package JavaScript repositories (monorepos) with git and npm
  • Dat is a new peer-to-peer protocol for sharing, archiving, and cataloging large data sets, that uses some of the concepts of BitTorrent and Git. Described in LWN.net article Sharing and archiving data sets with Dat by Antoine Beaupré. For other version control tools for Data Science see Git Rev News Edition #42.
  • LiteTree: SQLite with Branches is a modification of the SQLite engine to support branching, like Git
  • GitHooks.com is a guide to the wonders of git hooks, with the list of hooks, links to some articles about git hooks, and list of various related projects; accepts pull requests

Credits

This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Gabriel Alcaras <gabriel.alcaras@telecom-paristech.fr> with help from Johannes Schindelin and Luca Milanesio.