summaryrefslogtreecommitdiff
path: root/.gitattributes
diff options
context:
space:
mode:
authorLibravatar Patrick Steinhardt <ps@pks.im>2022-02-17 14:04:32 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2022-02-17 11:19:44 -0800
commit4f2ba2d06a7dd7e84e105a2779a7f07549d04231 (patch)
treef783e923168ba530f572ab8b0b2947ee8e7e004e /.gitattributes
parentfetch: report errors when backfilling tags fails (diff)
downloadtgif-4f2ba2d06a7dd7e84e105a2779a7f07549d04231.tar.xz
refs: add interface to iterate over queued transactional updates
There is no way for a caller to see whether a reference update has already been queued up for a given reference transaction. There are multiple alternatives to provide this functionality: - We may add a function that simply tells us whether a specific reference has already been queued. If implemented naively then this would potentially be quadratic in runtime behaviour if this question is asked repeatedly because we have to iterate over all references every time. The alternative would be to add a hashmap of all queued reference updates to speed up the lookup, but this adds overhead to all callers. - We may add a flag to `ref_transaction_add_update()` that causes it to skip duplicates, but this has the same runtime concerns as the first alternative. - We may add an interface which lets callers collect all updates which have already been queued such that he can avoid re-adding them. This is the most flexible approach and puts the burden on the caller, but also allows us to not impact any of the existing callsites which don't need this information. This commit implements the last approach: it allows us to compute the map of already-queued updates once up front such that we can then skip all subsequent references which are already part of this map. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to '.gitattributes')
0 files changed, 0 insertions, 0 deletions