summaryrefslogtreecommitdiff
path: root/oidset.h
AgeCommit message (Collapse)AuthorFilesLines
2018-01-08oidset: don't return value from oidset_initLibravatar Thomas Gummerer1-1/+1
c3a9ad3117 ("oidset: add iterator methods to oidset", 2017-11-21) introduced a 'oidset_init()' function in oidset.h, which has void as return type, but returns an expression. This makes the solaris compiler fail with: "oidset.h", line 30: void function cannot return value As the return type is void, and even the return type of the expression we're trying to return (oidmap_init) is void just remove the return statement to fix the compiler error. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22oidset: add iterator methods to oidsetLibravatar Jeff Hostetler1-0/+36
Add the usual iterator methods to oidset. Add oidset_remove(). Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-01oidmap: map with OID as keyLibravatar Jonathan Tan1-2/+4
This is similar to using the hashmap in hashmap.c, but with an easier-to-use API. In particular, custom entry comparisons no longer need to be written, and lookups can be done without constructing a temporary entry structure. This is implemented as a thin wrapper over the hashmap API. In particular, this means that there is an additional 4-byte overhead due to the fact that the first 4 bytes of the hash is redundantly stored. For now, I'm taking the simpler approach, but if need be, we can reimplement oidmap without affecting the callers significantly. oidset has been updated to use oidmap. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08add oidset APILibravatar Jeff King1-0/+45
This is similar to many of our uses of sha1-array, but it overcomes one limitation of a sha1-array: when you are de-duplicating a large input with relatively few unique entries, sha1-array uses 20 bytes per non-unique entry. Whereas this set will use memory linear in the number of unique entries (albeit a few more than 20 bytes due to hashmap overhead). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>