Re: Self-inflicted "abort" in a newbie attempt at read-only exploration of a cloned repository?

From: Jeff King <peff@peff.net>
Date: Apr 6, 2018, 19:56 UTC
Message-ID: <20180406195659.GD11450@sigill.intra.peff.net>
In-Reply-To: <CAGyf7-E9=Mm1oJdhwHTmg2byrOxMRFVEjmYHCFGqqP8pvK=vJg@mail.gmail.com>

On Thu, Apr 05, 2018 at 04:18:23PM -0700, Bryan Turner wrote:

Show 17 quoted lines

> 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. :(

-Peff