[RFC PATCH 0/3] Migrate the refs API to take the repository argument

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The second patch is the real API proposal.
Unlike the lookup_* series, which caused a lot of integration pain to Junio,
I plan to structure this in a different way, by having multiple steps:

 (1) in this (later to be non-RFC) series, add the new API that passes thru
     the repository; for now do not replace refs_store argument by
     struct repository.
 (2) the last patch is a demo of converting one of the callers over
     to the new API; this would need to be done for all of them
     
 (3) After some time do a cleanup series to remove callers of the
     old API fromly introduced series that are currently in flight.
 (4) Remove the old API.

 (5) Introduce the final API removing the refs_store
 (6) convert all callers to the final API, using this same dual step approach
 (7) remove this API
 
Steps 1,2 will be done in this series (2 is done only as demo here
for one function, but the non-RFC would do it all)

Steps 3,4 would be done once there are no more series in flight using
the old API.

Before continuing on step (2), I would want to ask for your thoughts
of (1).

Also note that after step (1) before (4) refs.h looks messy as well as
between (5) and (7).

Thanks,
Stefan


Stefan Beller (3):
  refs.c: migrate internal ref iteration to pass thru repository
    argument
  refs: introduce new API, wrap old API shallowly around new API
  replace: migrate to for_each_replace_repo_ref

 builtin/replace.c    |   9 +-
 refs.c               | 187 ++++++++++++++--------
 refs.h               | 362 ++++++++++++++++++++++++++++++++++++++-----
 refs/iterator.c      |   6 +-
 refs/refs-internal.h |   5 +-
 replace-object.c     |   7 +-
 6 files changed, 464 insertions(+), 112 deletions(-)

-- 
2.18.0.345.g5c9ce644c3-goog




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux