Re: [PATCH] Documentation/git-worktree: use working tree for trees on the file system

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

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

> -List details of each worktree.  The main worktree is listed first, followed by
> -each of the linked worktrees.  The output details include if the worktree is
> -bare, the revision currently checked out, and the branch currently checked out
> -(or 'detached HEAD' if none).
> +List details of each working tree.  The main working tree is listed first,
> +followed by each of the linked working trees.  The output details include if
> +the working tree is bare, the revision currently checked out, and the branch
> +currently checked out (or 'detached HEAD' if none).

I do not think this is correct.

Think of a "worktree" something that roughly corresponds to
different location you can refer to with $GIT_DIR.

A $GIT_DIR may be a true repository.  Or it may be borrowing many of
the things from its primary repository.  Even though "git worktree"
Porcelain may not currently be equipped to create a "bare" $GIT_DIR,
there is no fundamental reason that a secondary "worktree" must have
a working tree, i.e. a "worktree" could be a "bare" one (it would be
the first use of per-worktree config; a secondary worktree that is a
bare can be made by borrowing from the primary worktree that has a
working tree).

Now, what does "git worktree list" enumearate?  It does not list
"working trees"; its output are list of things, each of which you
could point at with $GIT_DIR and work with.




[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]