Re: [PATCH v2] worktree: allow to (re)move worktrees with uninitialized submodules

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jan 6, 2019, 07:01 UTC
Message-ID: <CAPig+cTt3JZKjE0Kq+ZaHfYvqvXOvtADGfb6kbRKiUTX2NDdQQ@mail.gmail.com>
In-Reply-To: <xmqqftu8avfu.fsf@gitster-ct.c.googlers.com>

On Fri, Jan 4, 2019 at 5:51 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
> > Uninitialized submodules have nothing valueable for us to be worried
> > about. They are just SHA-1. Let "worktree remove" and "worktree move"
> > continue in this case so that people can still use multiple worktrees
> > on repos with optional submodules that are never populated, like
> > sha1collisiondetection in git.git when checked out by doc-diff script.
>
> Is this a fair description for this 1-patch topic?
>
>         "git worktree remove" and "git worktree move" failed to work
>         when there is an uninitialized submodule, which has been fixed.

Saying "failed to work" makes it sound as if those two subcommands are broken or buggy, which is not the case. Instead, they are overly cautious and refuse to allow the operation if _any_ submodule (initialized or not) is detected. This patch just loosens that check to allow the operations to succeed for uninitialized submodules, thus avoiding this (existing) annoying behavior, using git.git as an example:

    % cd git
    % git worktree add --detach ../foo
    % git worktree remove ../foo
    fatal: working trees containing submodules cannot be moved or removed

Perhaps the change could instead be summarized as:

    "git worktree remove" and "git worktree move" were overly
    cautious, refusing to operate if any submodule was detected, even
    an uninitialized one. This safeguard has been refined to take only
    initialized submodules into account since worktrees with
    uninitialized ones can be safely removed and moved.