From: Junio C Hamano <gitster@pobox.com>
To: Michael Rappazzo <rappazzo@gmail.com>
Cc: sunshine@sunshineco.com, dturner@twopensource.com, git@vger.kernel.org
Subject: Re: [PATCH v8 3/4] worktree: add functions to get worktree details
Date: Tue, 22 Sep 2015 11:10:34 -0700 [thread overview]
Message-ID: <xmqqio72495x.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1442583027-47653-4-git-send-email-rappazzo@gmail.com> (Michael Rappazzo's message of "Fri, 18 Sep 2015 09:30:26 -0400")
Michael Rappazzo <rappazzo@gmail.com> writes:
> +/**
> + * get the main worktree
> + */
> +static struct worktree *get_main_worktree()
static struct worktree *get_main_worktree(void)
> +{
> + struct worktree *worktree = NULL;
> struct strbuf path = STRBUF_INIT;
> + struct strbuf worktree_path = STRBUF_INIT;
> + struct strbuf git_dir = STRBUF_INIT;
> + struct strbuf head_ref = STRBUF_INIT;
> + int is_bare = 0;
> + int is_detached = 0;
>
> + strbuf_addf(&git_dir, "%s", absolute_path(get_git_common_dir()));
> + strbuf_addf(&worktree_path, "%s", absolute_path(get_git_common_dir()));
Why not strbuf_add(&git_dir, absolute_path(get_git_common_dir()))
followed by strbuf_addbuf(&git_dir, &worktree_path)?
> + is_bare = !strbuf_strip_suffix(&worktree_path, "/.git");
> + if (is_bare)
> + strbuf_strip_suffix(&worktree_path, "/.");
Hmm, it is not immediately obvious which part is meant to be a
faithful translations from the old find_main_symref() that grab the
same kind of information the old code used to discover (and record
in a new mechanism that is "struct worktree"), and which part is a
new code that is needed to grab new pieces of information. The
effort in [PATCH 2/4] to make it easier to follow sort of lost by
this rewrite.
I presume that discovery of the git_dir is from the original and
everything else including is_bare bit, head_ref, is_detached are
new?
Splitting this patch further into two may help showing the changes
better. First move to the "grab information into an element of the
worktree array" code structure without adding new information, and
then "now make the worktree structure richer" as a follow up,
perhaps?
> +/**
> + * get the estimated worktree count for use in sizing the worktree array
> + * Note that the minimum count should be 2 (main worktree + NULL). Using the
> + * file count in $GIT_COMMON_DIR/worktrees includes '.' and '..' so the
> + * minimum is satisfied by counting those entries.
> + */
> +static int get_estimated_worktree_count()
> +{
> +...
> }
This is new. My gut-feeling is that we would probably not want to
do this (see below).
> +struct worktree **get_worktrees(void)
> {
> + struct worktree **list = NULL;
> struct strbuf path = STRBUF_INIT;
> DIR *dir;
> struct dirent *d;
> - char *existing;
> + int counter = 0;
> +
> + list = xmalloc(get_estimated_worktree_count() * sizeof(struct worktree *));
Here you scanned the directory to see how many possible worktrees
there are "at this moment".
Time passes.
How do you know that nobody added more worktrees in the meantime?
You don't.
>
> - if ((existing = find_main_symref(symref, target)))
> - return existing;
> + if ((list[counter] = get_main_worktree()))
> + counter++;
>
> strbuf_addf(&path, "%s/worktrees", get_git_common_dir());
> dir = opendir(path.buf);
> strbuf_release(&path);
> + if (dir) {
> + while ((d = readdir(dir)) != NULL) {
> + struct worktree *linked = NULL;
> + if (!strcmp(d->d_name, ".") || !strcmp(d->d_name, ".."))
> + continue;
> +
> + if ((linked = get_linked_worktree(d->d_name))) {
> + list[counter++] = linked;
Which means that nothing stops you from overrunning the list[] with
this iteration.
By the way, when the body of "if" and "else" both consists of a
single statement, we tend to drop braces.
> + }
And in order to avoid overrunning, you would need to do the usual
ALLOC_GROW() dance on list[] _anyway_. So there is no much point,
other than to optimize for a case where you have thousands of
worktrees and the usual ALLOC_GROW() approach would have to do
realloc(3) too many times, to have the initial "guestimate" scan.
next prev parent reply other threads:[~2015-09-22 18:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 13:30 [PATCH v8 0/4] worktree: list functions and command Michael Rappazzo
2015-09-18 13:30 ` [PATCH v8 1/4] worktree: add top-level worktree.c Michael Rappazzo
2015-09-22 17:16 ` Junio C Hamano
2015-09-18 13:30 ` [PATCH v8 2/4] worktree: refactor find_linked_symref function Michael Rappazzo
2015-09-22 17:44 ` Junio C Hamano
2015-09-18 13:30 ` [PATCH v8 3/4] worktree: add functions to get worktree details Michael Rappazzo
2015-09-22 18:10 ` Junio C Hamano [this message]
2015-09-18 13:30 ` [PATCH v8 4/4] worktree: add 'list' command Michael Rappazzo
2015-09-22 19:42 ` Junio C Hamano
2015-09-24 2:58 ` Mike Rappazzo
2015-09-24 5:00 ` Junio C Hamano
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=xmqqio72495x.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--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.