threads / discuss / 52297

Re: none

Subject: Re: none

## tl;dr

6 messages between Nov 20, 2019 and Nov 22, 2019.

replies: 5people: 4as markdown or json

Han-Wen Nienhuys· Nov 20, 2019, 03:49 UTC · lore

Hey folks,

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! -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Junio C Hamano· Nov 20, 2019, 04:52 UTC · re: Han-Wen Nienhuys · lore
Han-Wen Nienhuys <hanwen@google.com> writes:
Show 9 quoted lines
> 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.
Han-Wen Nienhuys· Nov 20, 2019, 05:00 UTC · re: Junio C Hamano · lore
On Tue, Nov 19, 2019 at 8:53 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> 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.

Thanks, i'll have a look at changing it. I use typedef mainly for ergonomics, but now that the code is written, I can introduce more verbosity.

> 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.

Transactions have to interface with the file system. I imagine that different libraries (libgit vs. cgit) would have different primitives for dealing with the file system, hence I haven't implemented that part. Do you have an idea of how I could implement it in a way that is agnostic of libgit2 vs. cgit?

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Han-Wen Nienhuys· Nov 22, 2019, 10:38 UTC · re: Junio C Hamano · lore

reftable (was: Re: none)

On Tue, Nov 19, 2019 at 8:53 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> > 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.
I changed the code to use struct throughout.
> 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.
I implemented the reftable stack in Go, see
  https://godoc.org/github.com/google/reftable#Stack
which I could implement in C too. Would that work?
-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
Taylor Blau· Nov 20, 2019, 05:30 UTC · re: Han-Wen Nienhuys · lore

Re: your mail

Hi Han-Wen,
On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
Show 9 quoted lines
> Hey folks,
>
> 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

Very exciting, and thanks for your work on this. I haven't taken a close look at the code yet, so I'm sure taking this further involves a much more careful examination.

I know that Christian Couder (who you CC-d on this thread) was also working on this for either GitLab or Booking.com.

Christian -- are you still working on this for either one of those entities? If so, is there some way to unify these two efforts?

> cheers!
> --

Thanks, Taylor

Christian Couder· Nov 20, 2019, 08:05 UTC · re: Taylor Blau · lore

Re: your mail

Hi Taylor and Han-Wen,
On Wed, Nov 20, 2019 at 6:30 AM Taylor Blau <me@ttaylorr.com> wrote:
Show 10 quoted lines
>
> On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> >
> > 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
Interesting!
Show 9 quoted lines
> Very exciting, and thanks for your work on this. I haven't taken a
> close look at the code yet, so I'm sure taking this further involves a
> much more careful examination.
>
> I know that Christian Couder (who you CC-d on this thread) was also
> working on this for either GitLab or Booking.com.
>
> Christian -- are you still working on this for either one of those
> entities? If so, is there some way to unify these two efforts?

Yeah, I started working on this last year for Booking.com, and I am now slowly working on it for GitLab. It is not yet finished because it has been low priority work.

I took a very quick look at Han-Wen's implementation and it looks very different from mine from the outside. It seems more complete, but might be less integrated into the Git code base.

Best, Christian.

← back to recent threads