Stolee said (privately):
I also ran into an issue where some of the "arbitrary repository"
patches don't fully connect. Jonathan's test demonstrated this
issue when I connected some things in an in-process patch
Work in progress: https://github.com/gitgitgadget/git/pull/11
Specifically: https://github.com/gitgitgadget/git/pull/11/commits/287ec6c1cd4bf4da76c05698373aee15749d011a
And I dislike the approach taken in
https://github.com/gitgitgadget/git/pull/11/commits/287ec6c1cd4bf4da76c05698373aee15749d011a
and would prefer another approach shown at
https://github.com/stefanbeller/git/tree/object-store-convert-refstore-partial
or in this series.
This approach doesn't have the ugliness of having the repository around twice,
e.g.
int register_replace_ref(const char *refname, ...
{
struct repository *r = cb_data;
...
}
...
for_each_replace_ref(r, register_replace_ref, r);
which would iterate over the refs of the first "r" and have "r" as a call back
data point for register_replace_ref.
This approach also takes the gentle hint of Junio to not replace well used functions
throughout the whole code base (using coccinelle), but for now exposes just
one example in the second patch.
These patches have been developed on top of jt/commit-graph-per-object-store.
Opinions?
Thanks,
Stefan
Stefan Beller (2):
refs.c: migrate internal ref iteration to pass thru repository
argument
refs.c: upgrade for_each_replace_ref to be a each_repo_ref_fn callback
builtin/replace.c | 3 ++-
refs.c | 48 +++++++++++++++++++++++++++++++++++++-------
refs.h | 12 ++++++++++-
refs/iterator.c | 6 +++---
refs/refs-internal.h | 5 +++--
replace-object.c | 3 ++-
6 files changed, 62 insertions(+), 15 deletions(-)
--
2.18.0.233.g985f88cf7e-goog
