git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [RFC] Git enumerations
@ 2018-08-20 17:59 Julian Ganz
  0 siblings, 0 replies; only message in thread
From: Julian Ganz @ 2018-08-20 17:59 UTC (permalink / raw)
  To: git@vger.kernel.org; +Cc: Matthias Beyer

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2018-08-20 20:05 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-20 17:59 [RFC] Git enumerations Julian Ganz

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).