From: David Turner <dturner@twopensource.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Michael Rappazzo <rappazzo@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
Git List <git@vger.kernel.org>
Subject: Re: [PATCH v6 1/2] worktree: add 'for_each_worktree' function
Date: Mon, 31 Aug 2015 14:44:34 -0400 [thread overview]
Message-ID: <1441046674.25570.15.camel@twopensource.com> (raw)
In-Reply-To: <CAPig+cTHZrQn8LpfftcsAQhFAykgDorbR97tkcuSCFYD_ngs9g@mail.gmail.com>
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.
next prev parent reply other threads:[~2015-08-31 18:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-30 19:10 [PATCH v6 0/2] worktree: for-each function and list command Michael Rappazzo
2015-08-30 19:10 ` [PATCH v6 1/2] worktree: add 'for_each_worktree' function Michael Rappazzo
2015-08-31 5:11 ` Eric Sunshine
2015-08-31 17:56 ` Junio C Hamano
2015-08-31 18:44 ` David Turner [this message]
2015-08-31 19:03 ` Eric Sunshine
2015-08-31 19:54 ` David Turner
2015-08-31 18:57 ` Mike Rappazzo
2015-08-31 19:22 ` Eric Sunshine
2015-08-31 19:47 ` Eric Sunshine
2015-08-31 19:54 ` Mike Rappazzo
2015-08-31 21:37 ` Eric Sunshine
2015-08-30 19:10 ` [PATCH v6 2/2] worktree: add 'list' command Michael Rappazzo
2015-08-31 6:23 ` Eric Sunshine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1441046674.25570.15.camel@twopensource.com \
--to=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rappazzo@gmail.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.