On Wed, Apr 3, 2019 at 6:15 PM Mark Kharitonov
<mark.kharitonov@xxxxxxxxx> wrote:
> C:\Dayforce\56 [release/r-856 ≡]> git --version
> git version 2.18.0.windows.1
> C:\Dayforce\56 [release/r-856 ≡]> git worktree list
> [...]
> C:/Dayforce/56 f9c36d3a2b [release/r-856]
> C:/Dayforce/56 f9c36d3a2b [release/r-856]
>
> Item #1 - how come I have two instances of release/r-856 in the git
> worktree list output?
>
> C:\Dayforce\56 [release/r-856 ≡]> git co onboarding/r-856/james-config
> Switched to branch 'onboarding/r-856/james-config'
> Your branch is up to date with 'origin/onboarding/r-856/james-config'.
> C:\Dayforce\56 [onboarding/r-856/james-config ≡]> git co release/r-856
> fatal: 'release/r-856' is already checked out at 'C:/Dayforce/56'
>
> Item #2 - why cannot I checkout release/r-856, if I am already in the
> right working tree? I suppose it is connected to item #1
You probably hit the bug reported in [1], which was fixed by [2] which
made it into Git 2.20.0. Specifically, prior to 2.20.0, you could get
invalid duplicate worktree entries like this:
$ git worktree add foo bar
$ rm -rf foo
$ git worktree add foo bar
$ git worktree list
...
foo deadbeef [bar]
foo deadbeef [bar]
If you don't have any changes in C:/Dayforce/56, an easy way to
recover from the situation is to blast the directory, prune the
worktree list, and re-create:
$ rm -rf C:/Dayforce/56
$ git worktree prune -v
$ git worktree list # just to verify that duplicate entries are gone
$ git worktree add C:/Dayforce/56 release/r-856
[1]: https://public-inbox.org/git/20180821193556.GA859@xxxxxxxxxxxxxxxxxxxxx/
[2]: https://public-inbox.org/git/20180828212026.21989-6-sunshine@xxxxxxxxxxxxxx/
