Re: [PATCH v2 05/14] commit-graph: implement git-commit-graph --write

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux