On Sat Nov 16, 2024 at 01:15, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Bence Ferdinandy" <bence@xxxxxxxxxxxxxx> writes: > >> 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. > >> ... 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
