Re: Bug report - Can create worktrees from bare repo / such worktrees can fool is_bare_repository()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Derrick Stolee <stolee@xxxxxxxxx> writes:

> Thanks for this context of added responsibility. It seems a bit strange
> to require this, since it doesn't make any sense to have a bare worktree
> (at least not to me, feel free to elaborate on the need of such a
> situation).

Stepping back a bit, those who want to have two new worktrees
attached to a single bare repository justify the wish by saying that
neither of these two new worktrees should be the primary thing that
they can lose to make the other inoperable, and having a dedicated
"shared object and ref store" repository makes it more symmetric and
safer by making it obvious which one is the precious thing to keep.

Wanting to create two new "bare repository lookalike" attached to a
single bare repository might be defensible the same way.

Not that the current "git worktree" has readily-available features
to create such a layout.  If people who have worked on "worktree"
did not see the possibility of needing such a layout, it is
understandable that such features wouldn't have been designed yet.

Also not that I think that such a layout necessarily makes sense.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux