git branch doesn't allow me to forcibly delete branch which was checked out in a now-deleted worktree dir

% git branch -D archive-extracted-xz
error: Cannot delete branch 'archive-extracted-xz' checked out at '/home/erik/git/salt/archive-extracted-xz'
% test -d /home/erik/git/salt/archive-extracted-xz || echo "directory doesn't exist"
directory doesn't exist
% git --version
git version 2.9.0

I know that I can just get rid of this error by pruning the worktrees,
but this still seems like incorrect behavior on the part of git branch.
It shouldn't be telling me that the branch is checked out in a directory
that does not exist, that is just factually incorrect.

--

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan

On Thu, Jul 7, 2016 at 11:44 AM, Erik Johnson [off-list ref] wrote:

% git branch -D archive-extracted-xz
error: Cannot delete branch 'archive-extracted-xz' checked out at
'/home/erik/git/salt/archive-extracted-xz'
% test -d /home/erik/git/salt/archive-extracted-xz || echo "directory
doesn't exist"
directory doesn't exist
% git --version
git version 2.9.0

I know that I can just get rid of this error by pruning the worktrees,
but this still seems like incorrect behavior on the part of git branch.
It shouldn't be telling me that the branch is checked out in a directory
that does not exist, that is just factually incorrect.

Until the worktree status is updated git branch probably isn't
checking itself. It might be worth triggering a worktree prune when
doing branch work. Note that some worktrees may be on removable media
or similar, and thus even if the directory doesn't exist right now,
that does not mean it's no longer checked out. There is already
support for setting a worktree as "persistent", but this means git
branch definitely shouldn't just do its own check for non existent
directory.

Thanks,
Jake

--

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan

On Thu, Jul 07, 2016 at 04:39:26PM -0700, Jacob Keller wrote:

On Thu, Jul 7, 2016 at 11:44 AM, Erik Johnson [off-list ref] wrote:

quoted

% git branch -D archive-extracted-xz
error: Cannot delete branch 'archive-extracted-xz' checked out at
'/home/erik/git/salt/archive-extracted-xz'
% test -d /home/erik/git/salt/archive-extracted-xz || echo "directory
doesn't exist"
directory doesn't exist
% git --version
git version 2.9.0

I know that I can just get rid of this error by pruning the worktrees,
but this still seems like incorrect behavior on the part of git branch.
It shouldn't be telling me that the branch is checked out in a directory
that does not exist, that is just factually incorrect.

Until the worktree status is updated git branch probably isn't
checking itself. It might be worth triggering a worktree prune when
doing branch work. Note that some worktrees may be on removable media
or similar, and thus even if the directory doesn't exist right now,
that does not mean it's no longer checked out. There is already
support for setting a worktree as "persistent", but this means git
branch definitely shouldn't just do its own check for non existent
directory.

Thanks,
Jake

I'm not expecting _any_ git branch command to prune worktrees, but a
branch _deletion_ shouldn't fail because git thinks the branch is
checked out in a worktree that doesn't exist anymore. Even in the
scenario where the worktree corresponding to that branch is on removable
media, does it really matter? You're trying to delete the branch.

I feel like this is a recent change in behavior, too. I've been using
worktrees since they were first available in 2.5, and I don't remember
having to prune to be able to delete the branch until recently.


--

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan

On Thu, Jul 7, 2016 at 5:36 PM, Erik Johnson [off-list ref] wrote:

I'm not expecting _any_ git branch command to prune worktrees, but a
branch _deletion_ shouldn't fail because git thinks the branch is
checked out in a worktree that doesn't exist anymore. Even in the
scenario where the worktree corresponding to that branch is on removable
media, does it really matter? You're trying to delete the branch.

I disagree. git branch -d (should) fail to delete a branch when it is
checked out in a worktree. If the worktree is a persistent (ie: not
there due to removable media etc)  directory then it *definitely*
shouldn't allow you to delete.

It is possible we should update "git branch -d" should perform a
worktree prune first, since that would enable it to determine that you
deleted the directory, and any worktree which is removable should be
marked as persistent.

Given that there is a known workaround (git worktree prune) and that
it is expected behavior for a branch checked out to prevent deletion,
I think the best coarse of action would be to patch git branch -d to
do a prune before attempting to delete.

Thanks,
Jake

On Fri, Jul 08, 2016 at 05:41:17PM -0700, Jacob Keller wrote:

On Thu, Jul 7, 2016 at 5:36 PM, Erik Johnson [off-list ref] wrote:

quoted

I'm not expecting _any_ git branch command to prune worktrees, but a
branch _deletion_ shouldn't fail because git thinks the branch is
checked out in a worktree that doesn't exist anymore. Even in the
scenario where the worktree corresponding to that branch is on removable
media, does it really matter? You're trying to delete the branch.

I disagree. git branch -d (should) fail to delete a branch when it is
checked out in a worktree. If the worktree is a persistent (ie: not
there due to removable media etc)  directory then it *definitely*
shouldn't allow you to delete.

It is possible we should update "git branch -d" should perform a
worktree prune first, since that would enable it to determine that you
deleted the directory, and any worktree which is removable should be
marked as persistent.

Given that there is a known workaround (git worktree prune) and that
it is expected behavior for a branch checked out to prevent deletion,
I think the best coarse of action would be to patch git branch -d to
do a prune before attempting to delete.

Thanks,
Jake

Well, I never mentioned -d (I was using -D), but I think we're both in
agreement.

--

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan

On Fri, Jul 8, 2016 at 7:22 PM, Erik Johnson [off-list ref] wrote:

On Fri, Jul 08, 2016 at 05:41:17PM -0700, Jacob Keller wrote:

quoted

It is possible we should update "git branch -d" should perform a
worktree prune first, since that would enable it to determine that you
deleted the directory, and any worktree which is removable should be
marked as persistent.

Given that there is a known workaround (git worktree prune) and that
it is expected behavior for a branch checked out to prevent deletion,
I think the best coarse of action would be to patch git branch -d to
do a prune before attempting to delete.

Thanks,
Jake

Well, I never mentioned -d (I was using -D), but I think we're both in
agreement.

Out of curiosity, what is git branch -D behavior when the worktree does exist?

Thanks,
Jake

On Fri, Jul 08, 2016 at 09:58:26PM -0700, Jacob Keller wrote:

On Fri, Jul 8, 2016 at 7:22 PM, Erik Johnson [off-list ref] wrote:

quoted

On Fri, Jul 08, 2016 at 05:41:17PM -0700, Jacob Keller wrote:

quoted

It is possible we should update "git branch -d" should perform a
worktree prune first, since that would enable it to determine that you
deleted the directory, and any worktree which is removable should be
marked as persistent.

Given that there is a known workaround (git worktree prune) and that
it is expected behavior for a branch checked out to prevent deletion,
I think the best coarse of action would be to patch git branch -d to
do a prune before attempting to delete.

Thanks,
Jake

Well, I never mentioned -d (I was using -D), but I think we're both in
agreement.

Out of curiosity, what is git branch -D behavior when the worktree does exist?

Thanks,
Jake

It works the same irrespective of whether or not the directory exists:

% git worktree add ../foo
Preparing ../foo (identifier foo)
HEAD is now at 91e095b Merge pull request #34429 from terminalmage/pkg-latest-versioncheck
% git branch -D foo
error: Cannot delete branch 'foo' checked out at '/home/erik/git/salt/foo'
% rm -rf /home/erik/git/salt/foo
% git branch -D foo
error: Cannot delete branch 'foo' checked out at '/home/erik/git/salt/foo'
% git worktree prune -v
Removing worktrees/foo: gitdir file points to non-existent location
% git branch -D foo
Deleted branch foo (was 91e095b).


--

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan

On Thu, Jul 7, 2016 at 8:44 PM, Erik Johnson [off-list ref] wrote:

% git branch -D archive-extracted-xz
error: Cannot delete branch 'archive-extracted-xz' checked out at
'/home/erik/git/salt/archive-extracted-xz'

This is from commit f292244 (branch -d: refuse deleting a branch which
is currently checked out - 2016-03-29) which is about -d not -D, so
it's probably an oversight. I think -D, as a forced form, should allow
deleting branches on other worktrees, we could simply detach the
worktree first.

It's worth noting that before that commit, -D refuses to delete branch
on current worktree as well and f292244 simply applies the same
behavior on other worktrees. If we change the -D behavior about
deleting branches on other worktrees, we may need to consider to keep
the behavior on current branch, or treat it equally as any other
worktrees.
-- 
Duy