On 2/2/2018 5:48 PM, Junio C Hamano wrote:
Stefan Beller <sbeller@xxxxxxxxxx> writes:
It is true for git-submodule and a few others (the minority of commands IIRC)
git-tag for example takes subcommands such as --list or --verify.
https://public-inbox.org/git/xmqqiomodkt9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/
Thanks. It refers to an article at gmane, which is not readily
accessible unless you use newsreader. The original discussion it
refers to appears at:
https://public-inbox.org/git/7vbo5itjfl.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/
for those who are interested.
Thanks for the links.
I am still not sure if it is a good design to add a new command like
this series does, though. I would naively have expected that this
would be a new pack index format that is produced by pack-objects
and index-pack, for example, in which case its maintenance would
almost be invisible to end users (i.e. just like how the pack bitmap
feature was added to the system).
I agree that the medium-term goal is to have this happen without user
intervention. Something like a "core.autoCommitGraph" setting to trigger
commit-graph writes during other cleanup activities, such as a repack or
a gc.
I don't think pairing this with pack-objects or index-pack is a good
direction, because the commit graph is not locked into a packfile the
way the bitmap is. In fact, the entire ODB could be replaced
independently and the graph is still valid (the commits in the graph may
no longer have their paired commits in the ODB due to a GC; you should
never navigate to those commits without having a ref pointing to them,
so this is not immediately a problem).
This sort of interaction with GC is one reason why I did not include the
automatic updates in this patch. The integration with existing
maintenance tasks will be worth discussion in its own right. I'd rather
demonstrate the value of having a graph (even if it is currently
maintained manually) and then follow up with a focus to integrate with
repack, gc, etc.
I plan to clean up this patch on Monday given the feedback I received
the last two days (Thanks Jonathan and Szeder!). However, if the current
builtin design will block merging, then I'll wait until we can find one
that works.
Thanks,
-Stolee
