summaryrefslogtreecommitdiff
path: root/Documentation/git-hash-object.txt
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2016-08-02 11:04:05 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2016-08-02 14:34:17 -0700
commit54ba5a1a16c0306bda1c304a341b9e4e7ab44684 (patch)
treee324f56a1fe38f384dca49dc14f822afaa8a852d /Documentation/git-hash-object.txt
parentGit 2.6.6 (diff)
downloadtgif-54ba5a1a16c0306bda1c304a341b9e4e7ab44684.tar.xz
hashmap: clarify that hashmap_entry can safely be discarded
The API documentation said that the hashmap_entry structure to be embedded in the caller's structure is to be treated as opaque, which left the reader wondering if it can safely be discarded when it no longer is necessary. If the hashmap_entry structure had references to external resources such as allocated memory or an open file descriptor, merely free(3)ing the containing structure (when the caller's structure is on the heap) or letting it go out of scope (when it is on the stack) would end up leaking the external resource. Document that there is no need for hashmap_entry_clear() that corresponds to hashmap_entry_init() to give the API users a little bit of peace of mind. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/git-hash-object.txt')
0 files changed, 0 insertions, 0 deletions