Re: [PATCH v4 20/21] refs: add LMDB refs storage backend

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

 



On Sat, Feb 6, 2016 at 2:44 AM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote:
> +static char *get_refdb_path(const char *base)
> +{
> +       static struct strbuf path_buf = STRBUF_INIT;
> +       strbuf_reset(&path_buf);
> +       strbuf_addf(&path_buf, "%s/refdb", base);
> +       return path_buf.buf;
> +}
...
> +static int lmdb_init_db(struct strbuf *err, int shared)
> +{
> +       /*
> +        * To create a db, all we need to do is make a directory for
> +        * it to live in; lmdb will do the rest.
> +        */
> +
> +       if (!db_path)
> +               db_path = xstrdup(real_path(get_refdb_path(get_git_common_dir())));

This works for multiple worktrees. But scripts may have harder time
getting the path. The recommended way is "git rev-parse --git-path
refdb" but because "refdb" is not registered in path.c:common_list[],
that command becomes git_path("refdb") instead of
get_refdb(get_git_... like here. And I will need to know that
.git/refdb is _not_ per-worktree when I migrate/convert main worktree
(it's very likely I have to go that route to solve .git/config issue
in multi worktree).

The solution is register refdb to common_list[] and you can do
git_path("refdb") here. But then what happens when another backend is
added? Will the new backend use the same path "refdb", or say
"refdb.sqlite"? If all backends share the name "refdb", why can't we
just reuse "refs" instead because the default filesystem-based backend
is technically just another backend?
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[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]