On Sat Nov 16, 2024 at 01:15, Junio C Hamano [off-list ref] wrote:

"Bence Ferdinandy" [off-list ref] writes:

quoted

Good point, and yes, that is what happens. (Although I'm not quite sure how
valid that state is where a remote's HEAD is not a branch).

Not often when you cloned from a publishing repository, but if you
cloned from a repository for your own work with an worktree, the
HEAD at such an origin repository may have been detached, so it
would be sensible (I think "git clone" historically guesses over
eagerly to hide the detached HEAD state of the other side, though)
if the clone's remote-tracking HEAD reflects it, I would think.

quoted

... So maybe if we put "Not a symbolic reference." in the referent
(which should be an invalid symref), the caller could check for that and then
should be able to distinguish this special case?

Yuck.

Are we limited by the narrow interface that only passes "referent",
or are you in the position that allows you to extend the interface
to "do it right"?

How about we do the following if we can't read a symref:

1) remember to return a new exit code for refs_update_symref_extended (I guess 2),
   but continue on with updating HEAD

2) read the non-symref ref into "referent" (I think this should not be able to
   fail since, otherwise locking HEAD will already fail earlier)

this way the caller can check the exit code, see that it's 2, so not entirely
a success, but HEAD has been updated and can report things accordingly.

Does that sounds more reasonable?

Thanks,
Bence