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.
Google Summer of Code 2018 wrap up
They have created repositories with a lot of information related to their work:
git stashto builtin
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!
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.
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
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.
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
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”.
git pushall the things
commit-msghook by Gabor Szabo
git log --graph,
--no-mergesby Dan Fabulich (2017)
Git tools and sites
cat(1)clone with syntax highlighting and Git integration
This edition of Git Rev News was curated by Christian Couder <email@example.com>, Jakub Narębski <firstname.lastname@example.org>, Markus Jansen <email@example.com> and Gabriel Alcaras <firstname.lastname@example.org> with help from Johannes Schindelin and Luca Milanesio.