Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > I spent the last few weeks cobbling together an implementation of the > reftable format in C and in Go. I thought this would be cool to add to > git-core, but I doubt whether I will have enough time to see such an > effort through. Maybe some of you would want to try integrating it > into the Git-core code base? Example code is here: > > https://github.com/google/reftable/blob/master/c/api.h#L153 > > cheers! My initial impression was that the API overuses typedef. We tend to avoid doing struct _foo { ... }; typedef struct _foo foo; and instead write "struct foo" explicitly to make us well aware of what we are talking about. That lets us see that we are passing or returning a structure by value (which we would like authors to think thrice before doing in C) like so quite easily: foo some_function(foo arg1, ...) { ... } because it would be clear if it were written like so struct foo some_function(struct foo arg1, ...) { ... } without hiding the structure behind a typedef (it also lets us avoid names with leading underscore, which is frowned upon by some people for different reasons). But the set of operations defined in the header file seemed at the right granularity in order to interface with the refs.h & refs/* API we have. It however was unclear to me how transactional ref updates would work with it. Thanks.
