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

Re: [PATCH/RFC 0/2] bisect per-worktree

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 3, 2015, 21:14 UTC
Message-ID
<xmqqvbcw6pml.fsf@gitster.dls.corp.google.com>
In-Reply-To
<1438631396.7348.33.camel@twopensource.com>
David Turner <dturner@twopensource.com> writes:
Show 8 quoted lines
> I think making this configurable is (a) overkill and (b) dangerous.
> It's dangerous because the semantics of which refs are per-worktree is
> important to the correct operation of git, and allowing users to mess
> with it seems like a big mistake.  Instead, we should figure out a
> simple scheme and define it globally.
>
> I think refs/worktree -> refs/worktrees/[worktree]/ would do fine as a
> fixed scheme, if we go that route.
OK.
> We would need two separate views of the refs hierarchy, though: one used
> by prune (and pack-refs) that is non-mapped (that is, includes
> per-worktree refs for each worktree), and one for general use that is
> mapped.   Maybe this is just a flag to the ref traversal functions.

True. Alternatively we could just view refs/worktree/* as if they are symbolic refs that point into refs/worktrees/$my_worktree/*, but that would imply making the latter always visible to all worktrees, which would hurt when people use it to interact with outside world (namely, refs in other people's private area should probably not be advertised).

Show 8 quoted lines
> As I understand it, we don't presently do many transactions that include
> both pseudorefs or per-worktree refs and other refs.  And we definitely
> don't want to move pseudorefs into the database since there's so much
> code that assumes they're files.  Also, the vast majority of refs are
> common, rather than per-worktree.  In fact, the only per-worktree refs
> I've seen mentioned so far are the bisect refs and NOTES_MERGE_REF and
> HEAD.  Of these, only HEAD is needed for pruning. Are there more that I
> haven't thought of?

I myself have come up with nothing other than the above. Let's hear from others.

> So I'm not sure the gain from moving per-worktree refs into the database
> is that great.
I am on the same wavelength as you are on this.
> There are some downsides of moving per-worktree refs into the database:
> ...
All good points except #3, which I cannot judge if it is good or bad.
> ...
> Simply treating refs/worktree as per-worktree, while the rest of refs/
> is not, would be a few dozen lines of code.  The full remapping approach
> is likely to be a lot more.

We may be over-engineering with Michael's and even with the more simpler refs/worktree/* -> refs/worktrees/$mine/* fixed mapping; I tend to agree with you.

Previous: David TurnerNext: Duy Nguyen
Message 11 of 15 in “bisect per-worktree”
  1. 0/2 bisect per-worktreeDavid Turner, Jul 31, 2015
  2. 1/2 refs: workree-refs/* become per-worktreeDavid Turner, Jul 31, 2015
  3. 2/2 bisect: make bisection refs per-worktreeDavid Turner, Jul 31, 2015
  4. Michael HaggertyAug 1, 2015
  5. Junio C HamanoAug 1, 2015
  6. David TurnerAug 1, 2015
  7. Michael HaggertyAug 1, 2015
  8. Junio C HamanoAug 2, 2015
  9. Duy NguyenAug 3, 2015
  10. David TurnerAug 3, 2015
  11. Junio C HamanoAug 3, 2015
  12. Duy NguyenAug 3, 2015
  13. David TurnerAug 3, 2015
  14. Duy NguyenAug 3, 2015
  15. Duy NguyenAug 3, 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.