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

Re: [PATCH v6 1/2] worktree: add 'for_each_worktree' function

From
David Turner <dturner@twopensource.com>
Date
Aug 31, 2015, 19:54 UTC
Message-ID
<1441050857.25570.21.camel@twopensource.com>
In-Reply-To
<CAPig+cTwtKgm4U64nZhRY+F5HuQvKk1RLdyAsS6sJfYp85go2A@mail.gmail.com>
On Mon, 2015-08-31 at 15:03 -0400, Eric Sunshine wrote:
Show 30 quoted lines
> On Mon, Aug 31, 2015 at 2:44 PM, David Turner <dturner@twopensource.com> wrote:
> > On Mon, 2015-08-31 at 01:11 -0400, Eric Sunshine wrote:
> >> Stepping back a bit, is a for-each-foo()-style interface desirable?
> >> This sort of interface imposes a good deal of complexity on callers,
> >> demanding a callback function and callback data (cb_data), and is
> >> generally (at least in C) more difficult to reason about than other
> >> simpler interfaces. Is such complexity warranted?
> >>
> >> An alternate, much simpler interface would be to have a function, say
> >> get_worktrees(), return an array of 'worktree' structures to the
> >> caller, which the caller would iterate over (which is a common
> >> operation in C, thus easily reasoned about).
> >>
> >> The one benefit of a for-each-foo()-style interface is that it's
> >> possible to "exit early", thus avoiding the cost of interrogating
> >> meta-data for worktrees in which the caller is not interested,
> >> however, it seems unlikely that there will be so many worktrees linked
> >> to a repository for this early exit to translate into any real
> >> savings.
> >
> > The other benefit is that there is no need to worry about deallocating
> > the list.  But that might be too minor to worry about.
> 
> Probably. The burden of having to deallocate the returned array seems
> quite minor compared to the complexity of the callback function
> approach.
> 
> Also, unstated but implied with the suggestion of a get_worktrees()
> function was that there would be a corresponding free_worktrees()
> function to make cleanup easy.

That's fine with me. Sorry for leading you down the wrong path, Michael.

Previous: Eric SunshineNext: Mike Rappazzo
Message 7 of 14 in “worktree: for-each function and list command”
  1. 0/2 worktree: for-each function and list commandMichael Rappazzo, Aug 30, 2015
  2. 1/2 worktree: add 'for_each_worktree' functionMichael Rappazzo, Aug 30, 2015
  3. Eric SunshineAug 31, 2015
  4. Junio C HamanoAug 31, 2015
  5. David TurnerAug 31, 2015
  6. Eric SunshineAug 31, 2015
  7. David TurnerAug 31, 2015
  8. Mike RappazzoAug 31, 2015
  9. Eric SunshineAug 31, 2015
  10. Eric SunshineAug 31, 2015
  11. Mike RappazzoAug 31, 2015
  12. Eric SunshineAug 31, 2015
  13. 2/2 worktree: add 'list' commandMichael Rappazzo, Aug 30, 2015
  14. Eric SunshineAug 31, 2015

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.