Re: Self-inflicted "abort" in a newbie attempt at read-only exploration of a cloned repository?
- From
- Thierry Moreau <thierry.moreau@connotech.com>
- Date
- Apr 6, 2018, 20:27 UTC
- Message-ID
- <5AC7D82A.8050806@connotech.com>
- In-Reply-To
- <20180406195659.GD11450@sigill.intra.peff.net>
On 06/04/18 07:56 PM, Jeff King wrote:
Show 33 quoted lines
> On Thu, Apr 05, 2018 at 04:18:23PM -0700, Bryan Turner wrote: > >> The documentation for --work-tree says: >> >> --work-tree=<path> >> >> Set the path to the working tree. It can be an absolute path or a path >> relative to the current working directory. This can also be controlled >> by setting the GIT_WORK_TREE environment variable and the >> core.worktree configuration variable (see core.worktree in >> git-config(1) for a more detailed discussion). >> >> So passing --work-tree tells Git where to store your _files_, but it's >> still using the same .git directory. >> >> If your goal is to have worktrees for various versions, that implies >> the git worktree [1] command might be more along the lines of what >> you're looking for. An invocation based on above might look like this: >> $ git -C linux-stable/ worktree add $PWD/tmp/ checkout linux-4.15.y > > Everything you've said here is completely accurate. But the original > report does make me wonder if we've set up users for failure by > overloading the term "worktree". Clearly it means two very different > things in: > > git --work-tree=foo > > and > > git worktree add foo > > I'm not sure what to do about it at this point, though. :( >
The documentation for 'git worktree add' was adequate for my problem solving process. My difficulty occurred because I used an earlier GIT version. The terminology overloading might not be a big issue.
Regards,
- Thierry