git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v5 2/5] refs: add ref_type function

From
David Turner <dturner@twopensource.com>
Date
Aug 3, 2015, 20:44 UTC
Message-ID
<1438634689.7348.35.camel@twopensource.com>
In-Reply-To
<CACsJy8DK9k67yM_mJqbqgDxNKdGKpoLPOQQ4beqGgzUobzyFUQ@mail.gmail.com>
On Mon, 2015-08-03 at 20:55 +0700, Duy Nguyen wrote:
Show 11 quoted lines
> On Fri, Jul 31, 2015 at 1:06 PM, David Turner <dturner@twopensource.com> wrote:
> > Add a function ref_type, which categorizes refs as per-worktree,
> > pseudoref, or normal ref.
> 
> For per-worktree refs, you probably should follow common_list[] in
> path.c because that's how file-based ref namespace is splitted between
> per-repo and per-worktree, even though just as simple as "everything
> outside refs/ is per-worktree" (with an exception of NOTES_MERGE_REF,
> which should be on the list as well). At least the two should be
> aligned so that the default file-based backend works the same way as
> new backends.

That would be cleaner, I think. I'm maybe a little worried about performance if we do this, but I guess we could optimize later.

Before I re-roll, I'll wait until we come to a conclusion on the other per-worktree ref thread.

I think we discussed NOTES_MERGE_REF[1], and decided that it should work like HEAD. Does that seem right to you?

Show 6 quoted lines
> Going further, I think you need to pass the "worktree identifier" to
> ref backend, at least in ref_transaction_begin_fn. Each backend is
> free to store per-worktree refs however it wants. Of course if I ask
> for refs/foo of worktree A, you should not return me refs/foo of
> worktree B. ref_transaction_begin_fn can return a fault code if it
> does not support multiple worktrees, which is fine.

If we did that, we would have to add it all over the place -- not just ref_transaction_begin, but also update_ref. 

I think it's better to encapsulate this knowledge inside the refs code.
Show 9 quoted lines
> > Later, we will use this in refs.c to treat pseudorefs specially.
> > Alternate ref backends may use it to treat both pseudorefs and
> > per-worktree refs differently.
> 
> I'm not so sure that this can't be hidden behind backends and they can
> have total control on falling back to file-based, or store them in
> some secondary storage. I haven't re-read your discussion with Junio
> yet (only skimmed through long ago) so I may be missing some important
> points.

The worry is symbolic refs -- a symbolic ref might be a per-worktree ref pointing to a shared ref pointing to a per-worktree ref. This is why it's simpler to let backends handle things. If we had some rules about this, we could maybe hide this from the backend, but so far, this was the simplest thing to do (it works great!).

[1] http://www.spinics.net/lists/git/msg256793.html
Previous: Duy NguyenNext: David Turner
Message 4 of 13 in “refs: introduce pseudoref and per-worktree ref concepts”
  1. 1/5 refs: introduce pseudoref and per-worktree ref conceptsDavid Turner, Jul 31, 2015
  2. 2/5 refs: add ref_type functionDavid Turner, Jul 31, 2015
  3. Duy NguyenAug 3, 2015
  4. David TurnerAug 3, 2015
  5. David TurnerAug 11, 2015
  6. 3/5 pseudorefs: create and use pseudoref update and delete functionsDavid Turner, Jul 31, 2015
  7. Stefan BellerJul 31, 2015
  8. David TurnerAug 11, 2015
  9. Junio C HamanoAug 11, 2015
  10. Junio C HamanoAug 11, 2015
  11. David TurnerAug 11, 2015
  12. 4/5 bisect: use update_refDavid Turner, Jul 31, 2015
  13. 5/5 sequencer: replace write_cherry_pick_head with update_refDavid Turner, Jul 31, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.