git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: some apparent inaccuracies in "man git-worktree"

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Nov 21, 2017, 19:44 UTC
Message-ID
<20171121194423.GH3429@aiede.mtv.corp.google.com>
In-Reply-To
<alpine.LFD.2.21.1711141509280.3970@localhost.localdomain>
Hi,
Robert P. J. Day wrote:
> On Tue, 14 Nov 2017, Eric Sunshine wrote:
>> On Tue, Nov 14, 2017 at 3:43 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
Show 11 quoted lines
>>> from "man git-worktree", there seem to be some inaccuracies in the
>>> SYNOPSIS regarding the "add" subcommand:
>>>
>>>   git worktree add \
>>>     [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<branch>]
>>>
>>>   first, there's no mention of "-B" in that SYNOPSIS, even though it's
>>> explained further down the man page.
>>
>> Omission of "-B" from the synopsis was intentional. From cbdf60fa18
>> (worktree: add -b/-B options, 2015-07-06):
[...]
>> Whether or not the omission was actually a good decision is
>> questionable.
[...]
>>>   next, the SYNOPSIS seems misleading as it doesn't make clear that
>>> the options -b, -B and --detach are mutually exclusive, which is made
>>> clear in the worktree.c source:
[...]
>> Failure to update the synopsis to indicate mutual exclusion appears to
>> be a simple oversight in ab0b2c53ed (worktree: make --detach mutually
>> exclusive with -b/-B, 2015-07-17)
[...]
Show 24 quoted lines
>>>   finally (and maybe i'm just not reading carefully enough), it's not
>>> clear what happens if you add a worktree at a given commit without
>>> specifying *any* of -b, -B or --detach. the obvious result should be a
>>> new worktree checked out at a detached HEAD and, interestingly, if i
>>> do that, then from the main tree, i see:
>>>
>>>   $ git worktree list
>>>   /home/rpjday/k/git   516fb7f2e73d [master]
>>>   /home/rpjday/k/temp  c470abd4fde4 (detached HEAD)
>>>   $
>>>
>>> but from within the worktree, if i ask for the status, i see only:
>>>
>>>   $ git status
>>>   Not currently on any branch.
>>>   nothing to commit, working tree clean
>>>   $
>>>
>>> where i would normally have expected to see "detached HEAD", is there
>>> a reason that's not displayed?
>>
>> Someone more familiar with this bit can correct me if I'm wrong, but I
>> believe that the "HEAD detached at/from <branch>" you normally see
>> with 'git status' is derived from the reflog,
[...]
>   i'm not sure what i can add to this, but i'm going to leave it to
> folks higher up the food chain than me to resolve any of the above.

For what it's worth, the folks higher up the food chain you're referring to don't exist, so the most likely outcome here is that nothing happens. People working on patches (suggesting wording, formatting as a patch, reviewing, testing, etc) are as high on the food chain as it gets. :)

One thing we've discussed on this list before is setting up a bug tracker to allow people another way to collaborate (filing a clear summary of a problem for interested people to work on). More on that subject later today --- feel free to poke me if I don't get such a message out.

Thanks, Jonathan

Previous: Robert P. J. Day
Message 4 of 4 in “some apparent inaccuracies in "man git-worktree"”
  1. Robert P. J. DayNov 14, 2017
  2. Eric SunshineNov 14, 2017
  3. Robert P. J. DayNov 14, 2017
  4. Jonathan NiederNov 21, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.