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

Re: [PATCH 6/9] pseudorefs: create and use pseudoref update and delete functions

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 24, 2015, 20:53 UTC
Message-ID
<xmqqa8ull1ki.fsf@gitster.dls.corp.google.com>
In-Reply-To
<1437769035.1141.16.camel@twopensource.com>
David Turner <dturner@twopensource.com> writes:
Show 16 quoted lines
> On Fri, 2015-07-24 at 12:25 -0700, Junio C Hamano wrote:
>> David Turner <dturner@twopensource.com> writes:
>> 
>> > Pseudorefs should not be updated through the ref API, because the ref
>> > API is for real refs.  Instead, use a dedicated pseudoref API.
>> >
>> > This patch changes writes to CHERRY_PICK_HEAD, REVERT_HEAD, and ORIG_HEAD.
>> 
>> This feels somewhat backwards, and it makes me wonder if it is a
>> better approach to teach update_ref() about the naming rules, so
>> that the callers do not have to say the same thing twice "This is
>> not a ref and I am giving all-caps name, by the way I am also not
>> calling update_ref() because that is only for real refs".
>
> Do you mean teach update_ref to call write_pseudoref for pseudorefs and
> call the normal codepath for regular refs?

While reviewing this series, I mostly am viewing them from the point of view of a user of the ref API.

You may name that "always delegate to filesystem backend" helper function "write_pseudoref()" or whatever name we (i.e. the ref API implementors) find easy to remember and understand, and as long as it is static within refs.c (or refs-be-file.c), a user of the ref API does not have to know. He does not have to care (ideally he shouldn't have to be able to call it directly, but that is merely a safety against bugs).

> I considered this, but I was worried about ref transactions.

Considering the nature of these FOO_HEADs, I think it is perfectly fine to declare that handling of them _must_ happen within a single transaction that does not involve regular refs, or that handling of them _must_ happen outside transactions. I do not think any of the existing creation, update, or deletion of these FOO_HEADs happen inside any transaction anyway.

Previous: David TurnerNext: David Turner
Message 16 of 20 in “Pseudorefs”
  1. 0/9 PseudorefsDavid Turner, Jul 24, 2015
  2. 1/9 refs: Introduce pseudoref and per-worktree ref conceptsDavid Turner, Jul 24, 2015
  3. Eric SunshineJul 24, 2015
  4. Junio C HamanoJul 24, 2015
  5. David TurnerJul 24, 2015
  6. Junio C HamanoJul 24, 2015
  7. Philip OakleyJul 24, 2015
  8. David TurnerJul 24, 2015
  9. 2/9 notes: replace pseudorefs with real refsDavid Turner, Jul 24, 2015
  10. 3/9 bisect: do not use update-ref for BISECT_HEADDavid Turner, Jul 24, 2015
  11. 4/9 tests: treat FETCH_HEAD as a pseudorefDavid Turner, Jul 24, 2015
  12. 5/9 tests: use --create-reflog option to git update-refDavid Turner, Jul 24, 2015
  13. 6/9 pseudorefs: create and use pseudoref update and delete functionsDavid Turner, Jul 24, 2015
  14. Junio C HamanoJul 24, 2015
  15. David TurnerJul 24, 2015
  16. Junio C HamanoJul 24, 2015
  17. 7/9 am/rebase: update pseudorefs by writing filesDavid Turner, Jul 24, 2015
  18. 8/9 rebase: use write_pseudorefDavid Turner, Jul 24, 2015
  19. 9/9 refs: forbid pseudoref updates through ref update APIDavid Turner, Jul 24, 2015
  20. Michael HaggertyAug 2, 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.