git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Shourya Shukla <shouryashukla.oo@gmail.com>
Cc: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Jonathan Müller" <jonathanmueller.dev@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Ramsay Jones" <ramsay@ramsayjones.plus.com>,
	"Git List" <git@vger.kernel.org>
Subject: Re: [PATCH v2 6/7] worktree: generalize candidate worktree path validation
Date: Wed, 10 Jun 2020 13:18:34 -0400	[thread overview]
Message-ID: <CAPig+cSLwPmDbk8Wjqb06OrNGHfmTLDOHjs88C+q1FhLGqLrrQ@mail.gmail.com> (raw)
In-Reply-To: <20200610171153.GA39055@konoha>

On Wed, Jun 10, 2020 at 1:12 PM Shourya Shukla
<shouryashukla.oo@gmail.com> wrote:
> On 10/06 02:30, Eric Sunshine wrote:
> > "git worktree add" checks that the specified path is a valid location
> > for a new worktree by ensuring that the path does not already exist and
> > is not already registered to another worktree (a path can be registered
> > but missing, for instance, if it resides on removable media). Since "git
> > worktree add" is not the only command which should perform such
> > validation ("git worktree move" ought to also), generalize the the
> > validation function for use by other callers, as well.
>
> There is an extra 'the' after generalize.

Thanks for noticing. I'll fix it if I re-roll, otherwise it can stay
(unless Junio happens to fix it when queuing).

> >    if (!wt)
> > -       goto done;
> > +       return;
>
> Should we do a 'return 1' on failure instead of just a blank 'return' so
> that we can denote failure of finding a worktree?

This function is declared as returning 'void', so we can't "return 1".
The function instead signals a problem by die()'ing.

Changing it to return a success or failure result rather than dying is
a different matter which can be done later if someone wants to do so,
but is outside the scope of this patch series which is only making the
minimal necessary changes to adapt the function for wider use.

> > -       die(_("'%s' is a missing but locked worktree;\nuse 'add -f -f' to override, or 'unlock' and 'prune' or 'remove' to clear"), path);
> > +       die(_("'%s' is a missing but locked worktree;\nuse '%s -f -f' to override, or 'unlock' and 'prune' or 'remove' to clear"), cmd, path);
>
> Let's wrap this to 72 characters at maximum per line maybe? Meaning that
> the error message gets split into 2 lines.

I'm not sure what you want to see wrapped; the warning message itself
or the source code line? As for the warning message, it already is
wrapped (see the embedded "\n").

At any rate, this patch makes the minimal change necessary to meet the
goal of making the function re-usable. Anything beyond that (such as
wrapping long lines) is outside the scope of the patch and would make
it harder to reason about the changes. Wrapping the line is certainly
something that someone can do later as a follow-up, but is not the
goal of this series.

> > -   validate_worktree_add(path, opts);
> > +   worktrees = get_worktrees(0);
> > +   check_candidate_path(path, opts->force, worktrees, "add");
> > +   free_worktrees(worktrees);
> > +   worktrees = NULL;
>
> It is necessary to call 'free_worktrees(worktrees)' at the end? The
> 'get_worktrees()' states that
>   The caller is responsible for freeing the memory from the returned
>   worktree(s).

This code _does_ call free_worktrees() as it should, so I'm not sure
what you're asking or saying. (Perhaps you're confusing "caller" and
"callee"?)

  reply	other threads:[~2020-06-10 17:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10  6:30 [PATCH v2 0/7] worktree: tighten duplicate path detection Eric Sunshine
2020-06-10  6:30 ` [PATCH v2 1/7] worktree: factor out repeated string literal Eric Sunshine
2020-06-10  6:30 ` [PATCH v2 2/7] worktree: give "should be pruned?" function more meaningful name Eric Sunshine
2020-06-10  6:30 ` [PATCH v2 3/7] worktree: make high-level pruning re-usable Eric Sunshine
2020-06-10  6:30 ` [PATCH v2 4/7] worktree: prune duplicate entries referencing same worktree path Eric Sunshine
2020-06-10 11:50   ` Shourya Shukla
2020-06-10 15:21     ` Eric Sunshine
2020-06-10 17:34       ` Junio C Hamano
2020-06-10  6:30 ` [PATCH v2 5/7] worktree: prune linked worktree referencing main " Eric Sunshine
2020-06-10  6:30 ` [PATCH v2 6/7] worktree: generalize candidate worktree path validation Eric Sunshine
2020-06-10 17:11   ` Shourya Shukla
2020-06-10 17:18     ` Eric Sunshine [this message]
2020-06-10  6:30 ` [PATCH v2 7/7] worktree: make "move" refuse to move atop missing registered worktree 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPig+cSLwPmDbk8Wjqb06OrNGHfmTLDOHjs88C+q1FhLGqLrrQ@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jonathanmueller.dev@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=ramsay@ramsayjones.plus.com \
    --cc=shouryashukla.oo@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).