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

Re: [PATCH v2 1/2] path: add a function to check for path suffix

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Aug 12, 2019, 22:40 UTC
Message-ID
<20190812224021.GA229582@genre.crustytoothpaste.net>
In-Reply-To
<xmqq7e7iba7j.fsf@gitster-ct.c.googlers.com>
On 2019-08-12 at 16:49:20, Junio C Hamano wrote:
Show 31 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
> >> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> >> > +static ssize_t stripped_path_suffix_offset(const char *path, const char *suffix)
> >> 
> >> Perhaps
> >> 
> >>     static ssize_t last_path_component_offset(const char *path, const char *name)
> >> 
> >> I am tempted to also call the second parameter to this function
> >> "basename", as we know from the proposed log message that you wish
> >> "basename" were usable for this purpose, but basename itself has
> >> another confusing factor (i.e. "are we stripping ".exe" extension?",
> >> to which the answer is no in the context of these functions).
> >> 
> >> If we agree with the "last path component" phrasing, has_path_suffix()
> >> would become something like:
> >> 
> >>     int last_path_component_equals(const char *path, const char *name);
> >
> > Except this is not necessarily the last path component. It could match
> > one or more path components with the way the function is written.
> 
> That's fair.  Is the feature that allows the function called
> ends_with_component*S* like Szeder suggests designed one, i.e. with
> an explicit purpose of supporting callers that pass "foo/bar" as the
> "suffix" to it, or is it merely that the implementation happens to
> work that way, even though the expected use that is supported is to
> pass only one level component but the implementation did not even
> bother asserting that the "suffix" does not have a slash in it?

Well, I split it out from a function that handles multiple path components, mostly so that I could leverage existing work (and not have to worry about getting it wrong). It wasn't explicitly intended that it support multiple components, since I don't require that for my implementation, but I could see future users taking advantage of that.

I think "ends_with_path_components" might be the way forward, unless you think something else would be better.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Previous: Junio C HamanoNext: Jeff King
Message 15 of 41 in “apply: reload .gitattributes after patching it”
  1. apply: reload .gitattributes after patching itbrian m. carlson, Aug 9, 2019
  2. Taylor BlauAug 9, 2019
  3. brian m. carlsonAug 9, 2019
  4. Jeff KingAug 9, 2019
  5. brian m. carlsonAug 9, 2019
  6. SZEDER GáborAug 9, 2019
  7. Jeff KingAug 9, 2019
  8. brian m. carlsonAug 9, 2019
  9. 0/2 Honor .gitattributes with rebase --ambrian m. carlson, Aug 11, 2019
  10. 1/2 path: add a function to check for path suffixbrian m. carlson, Aug 11, 2019
  11. Junio C HamanoAug 12, 2019
  12. brian m. carlsonAug 12, 2019
  13. SZEDER GáborAug 12, 2019
  14. Junio C HamanoAug 12, 2019
  15. brian m. carlsonAug 12, 2019
  16. Jeff KingAug 13, 2019
  17. Junio C HamanoAug 13, 2019
  18. SZEDER GáborAug 13, 2019
  19. Junio C HamanoAug 13, 2019
  20. 2/2 apply: reload .gitattributes after patching itbrian m. carlson, Aug 11, 2019
  21. 0/2 Honor .gitattributes with rebase --ambrian m. carlson, Aug 13, 2019
  22. 1/2 path: add a function to check for path suffixbrian m. carlson, Aug 13, 2019
  23. 2/2 apply: reload .gitattributes after patching itbrian m. carlson, Aug 13, 2019
  24. Junio C HamanoAug 13, 2019
  25. Junio C HamanoAug 15, 2019
  26. brian m. carlsonAug 16, 2019
  27. Junio C HamanoAug 13, 2019
  28. brian m. carlsonAug 13, 2019
  29. 0/2 Honor .gitattributes with rebase --ambrian m. carlson, Aug 18, 2019
  30. 1/2 path: add a function to check for path suffixbrian m. carlson, Aug 18, 2019
  31. 2/2 apply: reload .gitattributes after patching itbrian m. carlson, Aug 18, 2019
  32. Phillip WoodAug 19, 2019
  33. Phillip WoodAug 19, 2019
  34. brian m. carlsonAug 20, 2019
  35. Phillip WoodAug 20, 2019
  36. brian m. carlsonAug 20, 2019
  37. Phillip WoodAug 20, 2019
  38. Junio C HamanoAug 20, 2019
  39. Phillip WoodAug 20, 2019
  40. Phillip WoodAug 26, 2019
  41. Junio C HamanoAug 26, 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.