git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFC] Git enumerations

From
JGJulian Ganz <neither@nut.email>
Date
Aug 20, 2018, 17:59 UTC
Message-ID
<20180820195929.58444ae0@neithernut.Speedport_W_921V_1_39_000>
Hi list,
I'm a co-author of the git-dit tool [1] discussed in the thread
    git-bug: Distributed bug tracker embedded in git

on this mailing list. Partly motivated by Jonathan Nieder's call for more collaboration, I'd like to request comments on a functionality which I originally planned on introducing as a git-dit internal feature.

# Problem statement:

Especially with tools like git-dit or git-bug, we often list OIDs, usually of commits, and additional data. For example, `git dit list -a` may print something like the following (`-a` is for abbreviated ids):

8640a6b (Mon Dec 19 17:11:14 2016) Implement "subscribe" functionality ae058fd (Fri Dec 16 10:35:40 2016) Add features to dit-{list,show} to show statuses

For viewing the details of the first issue, you would invoke the "show" subcommand with the respective (possibly abbreviated) id. You generally either have to re-type or copy&paste this id. The first option tends to get on one's nerves, since the IDs have to be unambiguous for the repository. The second may disturb your workflow (since you have to grab your mouse) or may not be possible (e.g. plain TTY).

So it would be nice if you could just identify them via a plain number. For the output of `git log --oneline --decorate` and similar commands, we already have something similar: each commit shown can generally be addressed via some-ref~some-number. So you can, more or less, inspect those without copying IDs. For listing issues with git-dit, it's not that easy, since the issues are generally not connected.

# Solution using symbolic refs

When printing a list of disconnected objects addressable through OIDs, we would generate an enumeration on the fly. For each entry, we then store a symbolic ref reflecting the enumeration in some namespace (e.g. "refs/enumeration/1", "refs/enumeration/2", ...). Obviously, each symbolic ref would point to the respective entry's OID. Essentially, we have persisted the list printed by the first command.

Other subcommand of the tool would contain some minimal logic for detecting and choosing such an enumeration (e.g. "2") in the place of an OID.

This may have additional benefits for some tools, since we can also review a previously printed list. This is especially interesting if generating the list is costly.

# Additional tweaks

Instead of plain numbers, the symbolic refs could also contain an optional prefix. `git dit list`, for example could generate enumerations like "i1", "i2", ... while `git dit show` (which prints "messages") would generate "m1", "m2", "m3", ... This would support workflows like:

 * view the list of open issues
 * inspect an issue
 * show that (exact) list of issues again
 * inspect the next, ...

Alternatively, one could start using namespaces within "refs/enumeration", but imo this would hurt the usability in most cases.

# Integration

As stated initially, I originally planned on introducing this as an internal feature to git-dit. However, I realized that other tools may also benefit from such enumerations. Hence, I'm thinking about providing by a third-party library as well as a minimal tool/subcommand for managing (e.g. clearing) enumerations.

Regards, Julian

[1] https://github.com/neithernut/git-dit
Message 1 of 1 in “[RFC] Git enumerations”
  1. Julian GanzAug 20, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.