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

Re: [PATCH v3 1/1] worktree add: sanitize worktree names

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Feb 27, 2019, 14:23 UTC
Message-ID
<CAPig+cRJZBvwsptPOzx3oPSOnt6+uGLoyOr_JbUnku4kdSwdgA@mail.gmail.com>
In-Reply-To
<20190227120859.GB10305@sigill.intra.peff.net>
On Wed, Feb 27, 2019 at 7:09 AM Jeff King <peff@peff.net> wrote:
Show 25 quoted lines
> On Tue, Feb 26, 2019 at 05:58:51PM +0700, Nguyễn Thái Ngọc Duy wrote:
> > Update 'worktree add' code to remove special characters to follow
> > these rules. The code could replace chars with '-' more than
> > necessary, but it keeps the code simple. In the future the user will
> > be able to specify the worktree name by themselves if they're not
> > happy with this dumb character substitution.
>
> So notably this gets around ".." and ".lock" by just disallowing "."
> entirely. I think I'm OK with that for worktrees. It does make me a
> little nervous to see this new public function, though:
>
> > +int char_allowed_in_refname(int ch) [...]
>
> because it's not entirely accurate, as you noted above. I wonder if we
> could name this differently to warn people that the refname rules are
> not so simple.
>
> If we just cared about saying "is this worktree name valid", I'd suggest
> actually constructing a sample refname with the worktree name embedded
> in it and feeding that to check_refname_format(). But because you want
> to actually sanitize, I don't think there's an easy way to reuse it.
>
> So this approach is probably the best we can do, though I do still think
> it's worth renaming that function (and/or putting a big warning comment
> in front of it).

The above arguments seem to suggest the introduction of a companion to check_refname_format() for sanitizing, perhaps named sanitize_refname_format(), in ref.[hc]. The potential difficulty with that is defining exactly what "sanitize" means. Will it be contextual? (That is, will git-worktree have differently sanitation needs than some other facility?) If so, perhaps a 'flags' argument could control how sanitization is done.

Previous: Jeff KingNext: Jeff King
Message 20 of 41 in “git gc fails with "unable to resolve reference" for worktree”
  1. hi-angel@yandex.ruFeb 18, 2019
  2. Duy NguyenFeb 18, 2019
  3. hi-angel@yandex.ruFeb 18, 2019
  4. Duy NguyenFeb 18, 2019
  5. hi-angel@yandex.ruFeb 20, 2019
  6. worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Feb 21, 2019
  7. Konstantin KharlamovFeb 21, 2019
  8. Duy NguyenFeb 21, 2019
  9. Konstantin KharlamovFeb 21, 2019
  10. Duy NguyenFeb 21, 2019
  11. Jeff KingFeb 21, 2019
  12. 0/1 worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Feb 21, 2019
  13. 1/1 worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Feb 21, 2019
  14. Jeff KingFeb 21, 2019
  15. Ramsay JonesFeb 21, 2019
  16. Duy NguyenFeb 22, 2019
  17. 0/1 worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Feb 26, 2019
  18. 1/1 worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Feb 26, 2019
  19. Jeff KingFeb 27, 2019
  20. Eric SunshineFeb 27, 2019
  21. Jeff KingFeb 27, 2019
  22. Junio C HamanoMar 3, 2019
  23. Duy NguyenMar 4, 2019
  24. Duy NguyenMar 4, 2019
  25. Johannes SchindelinMar 4, 2019
  26. 0/2 worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Mar 5, 2019
  27. 1/2 refs.c: refactor check_refname_component()Nguyễn Thái Ngọc Duy, Mar 5, 2019
  28. Jeff KingMar 6, 2019
  29. Eric SunshineMar 7, 2019
  30. 2/2 worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Mar 5, 2019
  31. 0/1 worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Mar 8, 2019
  32. 1/1 worktree add: sanitize worktree namesNguyễn Thái Ngọc Duy, Mar 8, 2019
  33. Eric SunshineMar 10, 2019
  34. Junio C HamanoMar 11, 2019
  35. Duy NguyenMar 11, 2019
  36. Jeff KingMar 11, 2019
  37. Junio C HamanoMar 12, 2019
  38. Junio C HamanoMar 11, 2019
  39. Duy NguyenMar 11, 2019
  40. Johannes SchindelinMar 11, 2019
  41. Junio C HamanoMar 12, 2019

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.