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

Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs

From
David Turner <dturner@twopensource.com>
Date
Jul 9, 2015, 21:53 UTC
Message-ID
<1436478800.4542.61.camel@twopensource.com>
In-Reply-To
<xmqqmvz5x4cc.fsf@gitster.dls.corp.google.com>
On Wed, 2015-07-08 at 22:55 -0700, Junio C Hamano wrote:
Show 19 quoted lines
> David Turner <dturner@twopensource.com> writes:
> 
> > I didn't see this until after I had sent my previous message.  I think
> > the "multiple working trees" argument is strong enough that I will
> > change the code (and tests). 
> 
> Not just code, but we probably should step back a bit and clearly
> define what we are trying to achieve.  I _think_ what we want are:
> 
>  - Everything under refs/* and their associated logs would be handed
>    off to the "pluggable ref backend" when one is in use.
> 
>  - All ref-like things with one-level ALL_CAPS names are per working
>    tree.
> 
>    - They do not participate in "prunable?" reachability
>      computation.
>
>    - They (typically) do not want "logs".
Except HEAD definitely does.
Show 15 quoted lines
>    - Each may have extra information specific to it.
>    - You can however read an object name off of them.
> 
> One possible and straight-forward implementation to achieve
> "ref-like things with one-level ALL_CAPS names are per working tree"
> is to declare that they will not be handed off to the backend, but
> will always be implemented as files immediately under $GIT_DIR/.
> 
> But note that there is no fundamental reason we have to do it that
> way; an alternative would be to allow backends to store these things
> per working tree, but then the interface to drive backends need to
> tell them which working tree we are working from.
> 
> Unlike branches, HEAD must be per working tree; the "pluggable ref
> backend" needs to be able handle HEAD when you introduce it.

I actually punted on this in my implementation, because at the time, git-new-workdir was only in contrib. But since the new worktree stuff, multiple worktrees have first-class support, so I'll have to update the code to handle it.

Show 5 quoted lines
> So
> from that point of view, "multiple working tree" is *not* a valid
> argument why they *have* to be implemented as files under $GIT_DIR/.
> If you plan to let the pluggable ref backend to handle HEAD, you
> must have a solution for per working tree ref-like things anyway.
OK, here's my current best idea:
1. A "pseudoref" is an all-caps file in $GIT_DIR/ that always contains
at least a SHA1.  CHERRY_PICK_HEAD and REVERT_HEAD are examples. Because
HEAD might be a symbolic ref, it is not a pseudoref.

Refs backends do not manage pseudorefs. Instead, when a pseudoref (an all-caps ref containing no slashes) is requested (e.g. git rev-parse FETCH_HEAD) the generic refs code checks for the existence of that file and if it exists, returns immediately without hitting the backend. The generic code will refuse to allow updates to pseudorefs.

2. The pluggable refs backend manages all refs other than HEAD.
3. The "files" backend always manages HEAD.  This allows for a reflog
and for HEAD to be a symbolic ref.

The major complication here is ref transactions -- what if there's a transaction that wants to update e.g. both HEAD and refs/heads/master?

It may be the case that this never happens; I have not actually audited the code to figure it out. If someone knows for sure that it does not happen, please say so. But assuming it does happen, here's my idea:

If the refs backend is the files backend, we can simply treat HEAD like any other ref.

If the refs backend is different, then the refs code needs to hold a files-backend transaction for HEAD, which it will commit immediately after the other transaction succeeds. We can stick a pointer to the extra transaction in the generic struct ref_transaction, which (as Michael Haggerty suggests) specific backends will extend.

A failure to commit either transaction will be reported as a failure, and we'll give an additional inconsistent state warning if the main transaction succeeds but the HEAD transaction fails.

I don't love this idea -- it seems like kind of a hack. But it's the best I can come up with.

What do other folks think?
Show 8 quoted lines
> As to J6t's "no excessive plumbing invocations", I think the right
> approach is to have a single "git prompt--helper" command that does
> what the current script does to compute $r.  "we want to keep
> peeking into files under $GIT_DIR/" alone is not a valid enough
> reason to constrain us (I am fine if the solution we find
> appropriate for the 'multiple working trees' and other issues ends
> up being "we solve it by having them as files in $GIT_DIR" for other
> reasons, though).
Agree.
Previous: Junio C HamanoNext: Junio C Hamano
Message 9 of 30 in “refs.c: add err arguments to reflog functions”
  1. 1/8 refs.c: add err arguments to reflog functionsDavid Turner, Jul 8, 2015
  2. 2/8 cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refsDavid Turner, Jul 8, 2015
  3. Johannes SixtJul 8, 2015
  4. David TurnerJul 8, 2015
  5. Johannes SixtJul 8, 2015
  6. Junio C HamanoJul 8, 2015
  7. David TurnerJul 8, 2015
  8. Junio C HamanoJul 9, 2015
  9. David TurnerJul 9, 2015
  10. Junio C HamanoJul 9, 2015
  11. Michael HaggertyJul 10, 2015
  12. David TurnerJul 10, 2015
  13. David TurnerJul 14, 2015
  14. Junio C HamanoJul 15, 2015
  15. David TurnerJul 15, 2015
  16. David TurnerJul 8, 2015
  17. 3/8 bisect: treat BISECT_HEAD as a refDavid Turner, Jul 8, 2015
  18. 4/8 refs: Break out check for reflog autocreationDavid Turner, Jul 8, 2015
  19. 5/8 refs: new public ref function: safe_create_reflogDavid Turner, Jul 8, 2015
  20. Michael HaggertyJul 8, 2015
  21. 6/8 git-reflog: add exists commandDavid Turner, Jul 8, 2015
  22. 7/8 update-ref and tag: add --create-reflog argDavid Turner, Jul 8, 2015
  23. Michael HaggertyJul 8, 2015
  24. David TurnerJul 8, 2015
  25. 8/8 git-stash: use update-ref --create-reflog instead of creating filesDavid Turner, Jul 8, 2015
  26. Junio C HamanoJul 8, 2015
  27. Junio C HamanoJul 8, 2015
  28. Michael HaggertyJul 8, 2015
  29. Michael HaggertyJul 8, 2015
  30. David TurnerJul 8, 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.