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

Re: [PATCH 12/12] refs.c: fix handling of badly named refs

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 22, 2014, 20:41 UTC
Message-ID
<xmqqlhrlf7oe.fsf@gitster.dls.corp.google.com>
In-Reply-To
<1405549392-27306-13-git-send-email-sahlberg@google.com>
Ronnie Sahlberg <sahlberg@google.com> writes:
Show 17 quoted lines
> We currently do not handle badly named refs well :
> $ cp .git/refs/heads/master .git/refs/heads/master.....@\*@\\.
> $ git branch
>    fatal: Reference has invalid format: 'refs/heads/master.....@*@\.'
> $ git branch -D master.....@\*@\\.
>   error: branch 'master.....@*@\.' not found.
>
> But we can not really recover from a badly named ref with less than
> manually deleting the .git/refs/heads/<refname> file.
>
> Change resolve_ref_unsafe to take a flags field instead of a 'reading'
> boolean and update all callers that used a non-zero value for reading
> to pass the flag RESOLVE_REF_READING instead.
> Add another flag RESOLVE_REF_ALLOW_BAD_NAME that will make
> resolve_ref_unsafe skip checking the refname for sanity and use this
> from branch.c so that we will be able to call resolve_ref_unsafe on such
> refs when trying to delete it.
Makes sense.
Show 10 quoted lines
> Add checks for refname sanity when updating (not deleting) a ref in
> ref_transaction_update and in ref_transaction_create to make the transaction
> fail if an attempt is made to create/update a badly named ref.
> Since all ref changes will later go through the transaction layer this means
> we no longer need to check for and fail for bad refnames in
> lock_ref_sha1_basic.
>
> Change lock_ref_sha1_basic to not fail for bad refnames. Just check the
> refname, and print an error, and remember that the refname is bad so that
> we can skip calling verify_lock().
This is somewhat puzzling, though.
Show 6 quoted lines
> @@ -2180,6 +2196,8 @@ static struct ref_lock *lock_ref_sha1_basic(const char *refname,
>  		else
>  			unable_to_lock_index_die(ref_file, errno);
>  	}
> +	if (bad_refname)
> +		return lock;

Hmph. If the only offence was that the ref was named badly due to historically loose code, does the caller not still benefit from the verify-lock check to make sure that other people did not muck with the ref while we were planning to update it?

>  	return old_sha1 ? verify_lock(lock, old_sha1, mustexist) : lock;
>  
>   error_return:
Previous: Ronnie SahlbergNext: Ronnie Sahlberg
Message 23 of 26 in “Use ref transactions part 3”
  1. 00/12 Use ref transactions part 3Ronnie Sahlberg, Jul 16, 2014
  2. 01/12 wrapper.c: simplify warn_if_unremovableRonnie Sahlberg, Jul 16, 2014
  3. Junio C HamanoJul 18, 2014
  4. 02/12 wrapper.c: add a new function unlink_or_msgRonnie Sahlberg, Jul 16, 2014
  5. Junio C HamanoJul 18, 2014
  6. Junio C HamanoJul 18, 2014
  7. Ronnie SahlbergJul 22, 2014
  8. Junio C HamanoJul 22, 2014
  9. 03/12 refs.c: add an err argument to delete_ref_looseRonnie Sahlberg, Jul 16, 2014
  10. 04/12 refs.c: pass the ref log message to _create/delete/update instead of _commitRonnie Sahlberg, Jul 16, 2014
  11. 05/12 refs.c: pass NULL as *flags to read_ref_fullRonnie Sahlberg, Jul 16, 2014
  12. Junio C HamanoJul 18, 2014
  13. Ronnie SahlbergJul 22, 2014
  14. Ronnie SahlbergJul 22, 2014
  15. 06/12 refs.c: move the check for valid refname to lock_ref_sha1_basicRonnie Sahlberg, Jul 16, 2014
  16. Junio C HamanoJul 18, 2014
  17. 07/12 refs.c: call lock_ref_sha1_basic directly from commitRonnie Sahlberg, Jul 16, 2014
  18. 08/12 refs.c: pass a skip list to name_conflict_fnRonnie Sahlberg, Jul 16, 2014
  19. 09/12 refs.c: propagate any errno==ENOTDIR from _commit back to the callersRonnie Sahlberg, Jul 16, 2014
  20. 10/12 fetch.c: change s_update_ref to use a ref transactionRonnie Sahlberg, Jul 16, 2014
  21. 11/12 refs.c: make write_ref_sha1 staticRonnie Sahlberg, Jul 16, 2014
  22. 12/12 refs.c: fix handling of badly named refsRonnie Sahlberg, Jul 16, 2014
  23. Junio C HamanoJul 22, 2014
  24. Ronnie SahlbergJul 22, 2014
  25. Ronnie SahlbergJul 22, 2014
  26. Junio C HamanoJul 22, 2014

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.