git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Loftus-Mercer <Stephen.Loftus-Mercer@spacex.com>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: bug report for "git status"
Date: Wed, 2 Nov 2022 15:06:17 +0000	[thread overview]
Message-ID: <84cd66d955ed4188aad093cc306080d0@spacex.com> (raw)

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
Two git commands that should be identical produce different results. 

First command:
> git worktree add -d "c:\temp\junk\blah" 209134fc8f
> git status

Second command:
> git worktree add -d "c:\temp\junk\blah"
> cd "c:\temp\junk\blah"
> git checkout 209134fc8f
> git status

Full details discussed here:
https://stackoverflow.com/questions/74237452/why-is-there-a-difference-between-git-worktree-add-with-checkout-and-git-chec/74241950

What did you expect to happen? (Expected behavior)
I expected both "git status" calls to be identical results. They are not. 

I expected that both would output the following:
> c:\temp\junk\blah>git status
> HEAD detached at 209134fc8f
> nothing to commit, working tree clean


What happened instead? (Actual behavior)
The first worktree command, the one with the commit hash in the command, gave this status instead:
> c:\temp\junk\blah>git status
> Not currently on any branch.
> nothing to commit, working tree clean

What's different between what you expected and what actually happened?
I do not understand why the first command has no head. Worse, why does it have no commit listed at all? 
Clearly HEAD must be on *some* commit -- my workspace is synced to some set of files!. 

Anything else you want to add:
The Stack Overflow post gives a reasonable explanation of why this happens. I think the difference is irrelevant to most users. I would prefer that both commands result in the same result. If that is impossible, I would ask that at least the "git status" command be amended to ALWAYS include a commit hash since that's the primary way to figure out which files are currently synched in a directory. 

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.36.1.windows.1
cpu: x86_64
built from commit: e2ff68a2d1426758c78d023f863bfa1e03cbc768
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19044 
compiler info: gnuc: 11.3
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>


[Enabled Hooks]

                 reply	other threads:[~2022-11-02 15:11 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84cd66d955ed4188aad093cc306080d0@spacex.com \
    --to=stephen.loftus-mercer@spacex.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).