{"thread":{"id":"49172","subject":"[RFC] Git enumerations","startedAt":"2018-08-20T20:05:55Z","lastAt":"2018-08-20T20:05:55Z","messageCount":1,"participants":["Julian Ganz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"356135","messageId":"20180820195929.58444ae0@neithernut.Speedport_W_921V_1_39_000","threadId":"49172","inReplyTo":null,"subject":"[RFC] Git enumerations","fromName":"Julian Ganz","fromEmail":"neither@nut.email","sentAt":"2018-08-20T17:59:29Z","receivedAt":"2018-08-20T20:05:55Z","isPatch":false,"sender":{"key":"neither@nut.email","avatar":null},"body":"Hi list,\n\nI'm a co-author of the git-dit tool [1] discussed in the thread\n\n    git-bug: Distributed bug tracker embedded in git\n\non this mailing list. Partly motivated by Jonathan Nieder's call for\nmore collaboration, I'd like to request comments on a functionality\nwhich I originally planned on introducing as a git-dit internal\nfeature.\n\n\n# Problem statement:\n\nEspecially with tools like git-dit or git-bug, we often list OIDs,\nusually of commits, and additional data. For example, `git dit list -a`\nmay print something like the following (`-a` is for abbreviated ids):\n\n8640a6b (Mon Dec 19 17:11:14 2016) Implement \"subscribe\" functionality\nae058fd (Fri Dec 16 10:35:40 2016) Add features to dit-{list,show} to show statuses\n\nFor viewing the details of the first issue, you would invoke the \"show\"\nsubcommand with the respective (possibly abbreviated) id. You generally\neither have to re-type or copy&paste this id. The first option tends to\nget on one's nerves, since the IDs have to be unambiguous for the\nrepository. The second may disturb your workflow (since you have to\ngrab your mouse) or may not be possible (e.g. plain TTY).\n\nSo it would be nice if you could just identify them via a plain number.\nFor the output of `git log --oneline --decorate` and similar commands,\nwe already have something similar: each commit shown can generally be\naddressed via some-ref~some-number. So you can, more or less, inspect\nthose without copying IDs. For listing issues with git-dit, it's not\nthat easy, since the issues are generally not connected.\n\n\n# Solution using symbolic refs\n\nWhen printing a list of disconnected objects addressable through OIDs,\nwe would generate an enumeration on the fly. For each entry, we then\nstore a symbolic ref reflecting the enumeration in some namespace\n(e.g. \"refs/enumeration/1\", \"refs/enumeration/2\", ...). Obviously, each\nsymbolic ref would point to the respective entry's OID. Essentially, we\nhave persisted the list printed by the first command.\n\nOther subcommand of the tool would contain some minimal logic for\ndetecting and choosing such an enumeration (e.g. \"2\") in the place of\nan OID.\n\nThis may have additional benefits for some tools, since we can also\nreview a previously printed list. This is especially interesting if\ngenerating the list is costly.\n\n\n# Additional tweaks\n\nInstead of plain numbers, the symbolic refs could also contain an\noptional prefix. `git dit list`, for example could generate\nenumerations like \"i1\", \"i2\", ... while `git dit show` (which prints\n\"messages\") would generate \"m1\", \"m2\", \"m3\", ... This would support\nworkflows like:\n\n * view the list of open issues\n * inspect an issue\n * show that (exact) list of issues again\n * inspect the next, ...\n\nAlternatively, one could start using namespaces within\n\"refs/enumeration\", but imo this would hurt the usability in most cases.\n\n\n# Integration\n\nAs stated initially, I originally planned on introducing this as an\ninternal feature to git-dit. However, I realized that other tools may\nalso benefit from such enumerations. Hence, I'm thinking about\nproviding by a third-party library as well as a minimal tool/subcommand\nfor managing (e.g. clearing) enumerations.\n\n\nRegards,\nJulian\n\n[1] https://github.com/neithernut/git-dit\n"}]}