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

Re: Re* [PATCH v2 1/2] refs: refs/worktree/* become per-worktree

From
David Turner <dturner@twopensource.com>
Date
Aug 11, 2015, 21:42 UTC
Message-ID
<1439329355.5283.34.camel@twopensource.com>
In-Reply-To
<xmqqvbclpm3h.fsf@gitster.dls.corp.google.com>
On Tue, 2015-08-11 at 14:10 -0700, Junio C Hamano wrote:
Show 9 quoted lines
> David Turner <dturner@twopensource.com> writes:
> 
> > We need a place to stick refs for bisects in progress that is not
> > shared between worktrees.  So we use the refs/worktree/ hierarchy.
> 
> This is by itself OK, but to help existing Porcelains, most notably
> "gitk", I think refs/bisect/ hierarchy should be treated the same
> way.  Moving them out of refs/bisect/ to refs/worktree/bisect/ would
> not be a good idea.
What does gitk do that's relevant here?
> Because refs/worktree/ hierarchy is not needed right now, I think we
> can even live with just special casing refs/bisect/ the way this
> patch does, without adding refs/worktree/ support at this point.
There are a few reasons for refs/worktree hierarchy:
1. To make it easy to see the behavior of a ref at a glance.
2. To avoid too many different special-cases.

It's true that special-casing refs/bisect would make for fewer code changes for now, but I am worried that next week we'll discover a new situation where we'll want per-worktree refs and then we'll have to add more special-cases.

Show 9 quoted lines
> > Note that git for-each-ref may have inconsistent behavior (I think; I
> > haven't confirmed this), sometimes showing refs/worktree/* and sometimes
> > not.  In the long run, we should fix this, but right now, I don't know
> > that it matters, since the only refs affected are these bisect refs.
> 
> We should fix that before this hits 'master', preferrably before
> this hits 'next', especially if we add support for the more generic
> refs/worktree/.  If it is only for refs/bisect/, we might be OK, but
> I didn't think things through.

I will do this. Should for-each-ref include or exclude these refs? One simple way to do "include" is to always create the refs/worktree directory (when creating refs/).

I'll also fix the rest of the things you suggested.
Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 6 in “refs: refs/worktree/* become per-worktree”
  1. 1/2 refs: refs/worktree/* become per-worktreeDavid Turner, Aug 11, 2015
  2. 2/2 bisect: make bisection refs per-worktreeDavid Turner, Aug 11, 2015
  3. Re* [PATCH v2 1/2] refs: refs/worktree/* become per-worktreeJunio C Hamano, Aug 11, 2015
  4. David TurnerAug 11, 2015
  5. Junio C HamanoAug 11, 2015
  6. David TurnerAug 11, 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.