working directory status

working directory status

[Sivanandan Srilakshmanan]

Hi,

I am new to git. I have been reading the documentation on Pro Git.

I have checked out two working directory (test1 & test2) using the
"git worktree add --checkout" command.

When I run the "git status" in either (test1 or test2) on the checked
out folder, the "On branch <branch name>" displays the branch name
from the latest checkout (ie branch associated with  test2).

Could you please provide the correct syntax to display the branch name
associated with the respective folder.

Any assistance is greatly appreciated.

Thanks
Lakshman

Re: working directory status

[Pratyush Yadav]

On 17/11/19 11:55AM, Sivanandan Srilakshmanan wrote:
> Hi,
> 
> I am new to git. I have been reading the documentation on Pro Git.
> 
> I have checked out two working directory (test1 & test2) using the
> "git worktree add --checkout" command.
> 
> When I run the "git status" in either (test1 or test2) on the checked
> out folder, the "On branch <branch name>" displays the branch name
> from the latest checkout (ie branch associated with  test2).

This behaviour does not happen for me on Git v2.24.0. When I create 
multiple worktrees, 'git status' in each worktree directory shows the 
correct branch. What version of Git are you using?
 
> Could you please provide the correct syntax to display the branch name
> associated with the respective folder.

You can use 'git worktree list' to see a list of all the worktrees. The 
output of the list has 3 columns: path to the worktree, commit checked 
out, and the name of the branch checked out in that worktree.

Example output:

  $ git worktree list
  /home/pratyush/src/git  50b2267a2a [next]
  /home/pratyush/src/foo  50b2267a2a [foo]

The first worktree is in ~/src/git and has the branch 'next' checked 
out. The second is in ~/src/foo and has the branch 'foo' checked out.

That said, running 'git status' should still show you the correct branch 
name. Try updating Git to the latest version (v2.24.0), and try again.

-- 
Regards,
Pratyush Yadav

Re: working directory status

[Sivanandan Srilakshmanan]

Hi Pratyush,

Thank you so so so very much for responding quickly. I am learning git
to assist my teams skill up on git.

My current version is v2.23.0 which I downloaded and installed a month
ago. Nevertheless, I have downloaded and installed v2.24.0 and the
problem still persists.

I have the following environment variable set
GIT_DIR=C:\GitRepo
GIT_HOME=C:\tools\Git

Please find below output from my command.

C:\test\Local_Newfeature>git branch
* Local_Kumfeature_branch
  Local_MyTest_branch
+ Local_Newfeature_branch
+ Local_SGSfeature_branch
  Local_feature_branch


C:\test\Local_Newfeature>git worktree list
C:\GitRepo                (bare)
C:/test/Local_Kumfeature  b0a097e [Local_Kumfeature_branch]
C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch]
C:/test/Local_SGSfeature  b0a097e [Local_SGSfeature_branch]



C:\test\Local_Newfeature>git --work-tree=C:\test\Local_Newfeature status
On branch Local_Kumfeature_branch
Your branch is up to date with 'Lakshman/feature_branch'.

nothing to commit, working tree clean


Your assistance is greatly appreciated.

Thanks
Lakshman


On Sun, Nov 17, 2019 at 6:29 PM Pratyush Yadav <me@yadavpratyush.com> wrote:
>
> On 17/11/19 11:55AM, Sivanandan Srilakshmanan wrote:
> > Hi,
> >
> > I am new to git. I have been reading the documentation on Pro Git.
> >
> > I have checked out two working directory (test1 & test2) using the
> > "git worktree add --checkout" command.
> >
> > When I run the "git status" in either (test1 or test2) on the checked
> > out folder, the "On branch <branch name>" displays the branch name
> > from the latest checkout (ie branch associated with  test2).
>
> This behaviour does not happen for me on Git v2.24.0. When I create
> multiple worktrees, 'git status' in each worktree directory shows the
> correct branch. What version of Git are you using?
>
> > Could you please provide the correct syntax to display the branch name
> > associated with the respective folder.
>
> You can use 'git worktree list' to see a list of all the worktrees. The
> output of the list has 3 columns: path to the worktree, commit checked
> out, and the name of the branch checked out in that worktree.
>
> Example output:
>
>   $ git worktree list
>   /home/pratyush/src/git  50b2267a2a [next]
>   /home/pratyush/src/foo  50b2267a2a [foo]
>
> The first worktree is in ~/src/git and has the branch 'next' checked
> out. The second is in ~/src/foo and has the branch 'foo' checked out.
>
> That said, running 'git status' should still show you the correct branch
> name. Try updating Git to the latest version (v2.24.0), and try again.
>
> --
> Regards,
> Pratyush Yadav

Re: working directory status

[Johannes Sixt]

Am 17.11.19 um 12:07 schrieb Sivanandan Srilakshmanan:
> Hi Pratyush,
> 
> Thank you so so so very much for responding quickly. I am learning git
> to assist my teams skill up on git.
> 
> My current version is v2.23.0 which I downloaded and installed a month
> ago. Nevertheless, I have downloaded and installed v2.24.0 and the
> problem still persists.
> 
> I have the following environment variable set
> GIT_DIR=C:\GitRepo
> GIT_HOME=C:\tools\Git

Setting GIT_DIR without also setting GIT_WORKTREE is not a supported
use-case. Therefore, ...

> C:\test\Local_Newfeature>git branch
> * Local_Kumfeature_branch
>   Local_MyTest_branch
> + Local_Newfeature_branch
> + Local_SGSfeature_branch
>   Local_feature_branch
> 
> 
> C:\test\Local_Newfeature>git worktree list
> C:\GitRepo                (bare)
> C:/test/Local_Kumfeature  b0a097e [Local_Kumfeature_branch]
> C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch]
> C:/test/Local_SGSfeature  b0a097e [Local_SGSfeature_branch]

... this does not work as expected, ....

> C:\test\Local_Newfeature>git --work-tree=C:\test\Local_Newfeature status
> On branch Local_Kumfeature_branch
> Your branch is up to date with 'Lakshman/feature_branch'.
> 
> nothing to commit, working tree clean

... but this works (--work-tree is the same as setting GIT_WORKTREE).

Nobody sets GIT_DIR during normal day-to-day work. Do not set it unless
you know what you are doing.

-- Hannes

Re: working directory status

[Sivanandan Srilakshmanan]

Hi Hannes,

Thank you for taking the time to guide me.

Reading git documentation, my understanding is that, if you needed to
use "git worktree add" then it is recommended to keep your work tree
(Working Dir) outside of your repository.
My understanding, please correct me if I am wrong, is to have multiple
worktree outside of the Git Repository.

if you used "git clone" to setup your directory and your worktree is
included in the same location as the Git Repository, then GIT_DIR is
not required.

Please assist me to understand what I am doing incorrectly. The
"output 1" below is incorrect because Local_Newfeature (working
directory / worktree) is associated with the incorrect branch
(Local_Kumfeature_branch)
Local_Newfeature directory should be pointing to "Local_Newfeature_branch".

Output 2 is correct.

====== Output 1 - incorrect =========================================
C:\test\Local_Newfeature>git --work-tree=C:\test\Local_Newfeature status
On branch Local_Kumfeature_branch
Your branch is up to date with 'Lakshman/feature_branch'.

nothing to commit, working tree clean


===== Output 2  - correct =============================================
C:\test\Local_Newfeature>git branch
* Local_Kumfeature_branch
  Local_MyTest_branch
+ Local_Newfeature_branch
+ Local_SGSfeature_branch
  Local_feature_branch


C:\test\Local_Newfeature>git worktree list
C:\GitRepo                (bare)
C:/test/Local_Kumfeature  b0a097e [Local_Kumfeature_branch]
C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch]
C:/test/Local_SGSfeature  b0a097e [Local_SGSfeature_branch]

Thank you for your assistance and guidance in advance.

Lakshman

On Sun, Nov 17, 2019 at 11:30 PM Johannes Sixt <j6t@kdbg.org> wrote:
>
> Am 17.11.19 um 12:07 schrieb Sivanandan Srilakshmanan:
> > Hi Pratyush,
> >
> > Thank you so so so very much for responding quickly. I am learning git
> > to assist my teams skill up on git.
> >
> > My current version is v2.23.0 which I downloaded and installed a month
> > ago. Nevertheless, I have downloaded and installed v2.24.0 and the
> > problem still persists.
> >
> > I have the following environment variable set
> > GIT_DIR=C:\GitRepo
> > GIT_HOME=C:\tools\Git
>
> Setting GIT_DIR without also setting GIT_WORKTREE is not a supported
> use-case. Therefore, ...
>
> > C:\test\Local_Newfeature>git branch
> > * Local_Kumfeature_branch
> >   Local_MyTest_branch
> > + Local_Newfeature_branch
> > + Local_SGSfeature_branch
> >   Local_feature_branch
> >
> >
> > C:\test\Local_Newfeature>git worktree list
> > C:\GitRepo                (bare)
> > C:/test/Local_Kumfeature  b0a097e [Local_Kumfeature_branch]
> > C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch]
> > C:/test/Local_SGSfeature  b0a097e [Local_SGSfeature_branch]
>
> ... this does not work as expected, ....
>
> > C:\test\Local_Newfeature>git --work-tree=C:\test\Local_Newfeature status
> > On branch Local_Kumfeature_branch
> > Your branch is up to date with 'Lakshman/feature_branch'.
> >
> > nothing to commit, working tree clean
>
> ... but this works (--work-tree is the same as setting GIT_WORKTREE).
>
> Nobody sets GIT_DIR during normal day-to-day work. Do not set it unless
> you know what you are doing.
>
> -- Hannes

Re: working directory status

[Johannes Sixt]

Am 17.11.19 um 21:33 schrieb Sivanandan Srilakshmanan:
> Reading git documentation, my understanding is that, if you needed to
> use "git worktree add" then it is recommended to keep your work tree
> (Working Dir) outside of your repository.
> My understanding, please correct me if I am wrong, is to have multiple
> worktree outside of the Git Repository.

That sounds reasonable. Note though that if you need N worktrees, then
you have one worktree with the (non-bare) repository, and N-1 worktrees
outside that repository.

> if you used "git clone" to setup your directory and your worktree is
> included in the same location as the Git Repository, then GIT_DIR is
> not required.

Yes.

> Please assist me to understand what I am doing incorrectly. The
> "output 1" below is incorrect because Local_Newfeature (working
> directory / worktree) is associated with the incorrect branch
> (Local_Kumfeature_branch)
> Local_Newfeature directory should be pointing to "Local_Newfeature_branch".
> 
> Output 2 is correct.
> 
> ====== Output 1 - incorrect =========================================
> C:\test\Local_Newfeature>git --work-tree=C:\test\Local_Newfeature status
> On branch Local_Kumfeature_branch
> Your branch is up to date with 'Lakshman/feature_branch'.

You observe this incorrect output because you have GIT_DIR set.
Obvously, Git looks at the branch that the HEAD of $GIT_DIR refers to.

Do not set GIT_DIR if you do not know what it is good for.

> ===== Output 2  - correct =============================================
> C:\test\Local_Newfeature>git branch
> * Local_Kumfeature_branch
>   Local_MyTest_branch
> + Local_Newfeature_branch
> + Local_SGSfeature_branch
>   Local_feature_branch

If Output 1 is incorrect, this is not correct, either: Note that
Local_Kumfeature_branch is marked as the branch for this directory, but
you intend it to be Local_Newfeature_branch, yet it is marked as living
in a different worktree.

Do not set GIT_DIR if you do not understand the consequences.

> C:\test\Local_Newfeature>git worktree list
> C:\GitRepo                (bare)
> C:/test/Local_Kumfeature  b0a097e [Local_Kumfeature_branch]
> C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch]
> C:/test/Local_SGSfeature  b0a097e [Local_SGSfeature_branch]

I do not know whether it is a sane use-case to have a bare repository
and separate worktrees.

Do not do that. Make a regular clone with a worktree and create
secondary worktrees from there.

-- Hannes

Re: working directory status

[Sivanandan Srilakshmanan]

Hi Hannes,

Thank you so very very, very much for your guidance.

My team and I maintain multiple projects, each with it's own remotely
hosted git repository.

I was reluctant to create clones of each project on my local machine
each with it's own "main working tree"

I figured:-

I could setup a "Local bare repository" and create remote link to the
hosted git repositories.
(https://git-scm.com/docs/git-worktree#_list_output_format)

Create "Local branches" when needed. Create a "linked working tree"
associated with the local branch.

Clean up the linked working tree when work is complete.



This way I can have a single repository pointing to multiple remote
repositories on one side and managing multiple local directories on my
PC.
In summary, my local repository will be conduit. I guess this is not possible.

Based on my requirement would you suggest the best approach would be
to create git clone for each remote repository?

Thanks again for your help and guidance.

Thanks
Lakshman

On Mon, Nov 18, 2019 at 9:26 AM Johannes Sixt <j6t@kdbg.org> wrote:
>
> Am 17.11.19 um 21:33 schrieb Sivanandan Srilakshmanan:
> > Reading git documentation, my understanding is that, if you needed to
> > use "git worktree add" then it is recommended to keep your work tree
> > (Working Dir) outside of your repository.
> > My understanding, please correct me if I am wrong, is to have multiple
> > worktree outside of the Git Repository.
>
> That sounds reasonable. Note though that if you need N worktrees, then
> you have one worktree with the (non-bare) repository, and N-1 worktrees
> outside that repository.
>
> > if you used "git clone" to setup your directory and your worktree is
> > included in the same location as the Git Repository, then GIT_DIR is
> > not required.
>
> Yes.
>
> > Please assist me to understand what I am doing incorrectly. The
> > "output 1" below is incorrect because Local_Newfeature (working
> > directory / worktree) is associated with the incorrect branch
> > (Local_Kumfeature_branch)
> > Local_Newfeature directory should be pointing to "Local_Newfeature_branch".
> >
> > Output 2 is correct.
> >
> > ====== Output 1 - incorrect =========================================
> > C:\test\Local_Newfeature>git --work-tree=C:\test\Local_Newfeature status
> > On branch Local_Kumfeature_branch
> > Your branch is up to date with 'Lakshman/feature_branch'.
>
> You observe this incorrect output because you have GIT_DIR set.
> Obvously, Git looks at the branch that the HEAD of $GIT_DIR refers to.
>
> Do not set GIT_DIR if you do not know what it is good for.
>
> > ===== Output 2  - correct =============================================
> > C:\test\Local_Newfeature>git branch
> > * Local_Kumfeature_branch
> >   Local_MyTest_branch
> > + Local_Newfeature_branch
> > + Local_SGSfeature_branch
> >   Local_feature_branch
>
> If Output 1 is incorrect, this is not correct, either: Note that
> Local_Kumfeature_branch is marked as the branch for this directory, but
> you intend it to be Local_Newfeature_branch, yet it is marked as living
> in a different worktree.
>
> Do not set GIT_DIR if you do not understand the consequences.
>
> > C:\test\Local_Newfeature>git worktree list
> > C:\GitRepo                (bare)
> > C:/test/Local_Kumfeature  b0a097e [Local_Kumfeature_branch]
> > C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch]
> > C:/test/Local_SGSfeature  b0a097e [Local_SGSfeature_branch]
>
> I do not know whether it is a sane use-case to have a bare repository
> and separate worktrees.
>
> Do not do that. Make a regular clone with a worktree and create
> secondary worktrees from there.
>
> -- Hannes

Re: working directory status

[Johannes Sixt]

Am 18.11.19 um 05:32 schrieb Sivanandan Srilakshmanan:
> Hi Hannes,
> 
> Thank you so very very, very much for your guidance.
> 
> My team and I maintain multiple projects, each with it's own remotely
> hosted git repository.
> 
> I was reluctant to create clones of each project on my local machine
> each with it's own "main working tree"
> 
> I figured:-
> 
> I could setup a "Local bare repository" and create remote link to the
> hosted git repositories.
> (https://git-scm.com/docs/git-worktree#_list_output_format)
> 
> Create "Local branches" when needed. Create a "linked working tree"
> associated with the local branch.
> 
> Clean up the linked working tree when work is complete.
> 
> 
> 
> This way I can have a single repository pointing to multiple remote
> repositories on one side and managing multiple local directories on my
> PC.
> In summary, my local repository will be conduit. I guess this is not possible.

I think it is possible. Just don't make it a bare repository if you need
to create secondary worktrees. (But maybe it even works if it is bare;
just don't set GIT_DIR; I don't do it this way, so I cannot tell.)

> Based on my requirement would you suggest the best approach would be
> to create git clone for each remote repository?

That is probably easier.

-- Hannes

Re: working directory status

[Eric Sunshine]

On Mon, Nov 18, 2019 at 1:51 AM Johannes Sixt <j6t@kdbg.org> wrote:
> Am 18.11.19 um 05:32 schrieb Sivanandan Srilakshmanan:
> > I was reluctant to create clones of each project on my local machine
> > each with it's own "main working tree"
> >
> > I figured:-
> >
> > I could setup a "Local bare repository" and create remote link to the
> > hosted git repositories.
> > (https://git-scm.com/docs/git-worktree#_list_output_format)
> >
> > Create "Local branches" when needed. Create a "linked working tree"
> > associated with the local branch.
> >
> > This way I can have a single repository pointing to multiple remote
> > repositories on one side and managing multiple local directories on my
> > PC.
> > In summary, my local repository will be conduit. I guess this is not possible.
>
> I think it is possible. Just don't make it a bare repository if you need
> to create secondary worktrees. (But maybe it even works if it is bare;
> just don't set GIT_DIR; I don't do it this way, so I cannot tell.)

git-worktree explicitly supports the use-case of the main worktree
being bare. (Of course, in this case, it's a misnomer to call it the
"main _worktree_", but the terminology was already established by the
time explicit support for bareness was added, so the term "main
worktree" stuck.)

Re: working directory status

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> ...
> Do not set GIT_DIR if you do not understand the consequences.

I think the explanation in your earlier message was probably a bit
more helpful.  If they want to use GIT_DIR, they need to also set
and export GIT_WORK_TREE.

Of course, with both exported, asking "git branch" for which branch
is checked out would ask about the working tree that GIT_WORK_TREE
points at without consulting $(pwd), so it is rather pointless.
When the user switches to another worktree, both GIT_DIR and
GIT_WORK_TREE need to be updated to point at appropriate places, so
it sort of defeats the purpose.

>
>> C:\test\Local_Newfeature>git worktree list
>> C:\GitRepo                (bare)
>> C:/test/Local_Kumfeature  b0a097e [Local_Kumfeature_branch]
>> C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch]
>> C:/test/Local_SGSfeature  b0a097e [Local_SGSfeature_branch]
>
> I do not know whether it is a sane use-case to have a bare repository
> and separate worktrees.
>
> Do not do that. Make a regular clone with a worktree and create
> secondary worktrees from there.

As long as GIT_DIR/GIT_WORK_TREE are both set and exported (or both
unset, a new worktree made out of a bare clone should work just
fine.  At least that is one of the use case I recall the feature was
designed to be used in.

Thanks.

Re: working directory status

[Sivanandan Srilakshmanan]

Hi Hannes, Junio, Eric & Pratyush

Thank you very much for your support. I greatly appreciate your guidance.

It is clear now and it is working well. It is possible to use a local
bare repository as a conduit to manage multiple remote repositories.

I had to re-read the https://git-scm.com/docs keeping in mind the
guidance given, to get a better handle on it.

For the benefit of anyone else stumbling across this thread.

As mentioned earlier ****  DON'T  ***  set GIR_DIR and GIT_WORK_TREE.

Step 1. create a git repo (bare/non-bare)
Step 2. git worktree add --track -b    Local_Newfeature_branch1
Local_Newfeature       remotes/Lakshman/feature_branch

The above will create a local branch Local_Newfeature_branch1
The above command will also checkout the code into  the directory
Local_Newfeature.

You can perform all your git command inside the directory Local_Newfeature.

C:\test\Local_Newfeature>git branch
  Local_Newfeature_branch
* Local_Newfeature_branch1
  Local_feature_branch

C:\test\Local_Newfeature>git worktree list
C:/GitRepo                (bare)
C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch1]



Works like a charm. Thank you all very, very very much for your
guidance and feedback much appreciated.

Thanks
Lakshman


On Mon, Nov 18, 2019 at 6:12 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Johannes Sixt <j6t@kdbg.org> writes:
>
> > ...
> > Do not set GIT_DIR if you do not understand the consequences.
>
> I think the explanation in your earlier message was probably a bit
> more helpful.  If they want to use GIT_DIR, they need to also set
> and export GIT_WORK_TREE.
>
> Of course, with both exported, asking "git branch" for which branch
> is checked out would ask about the working tree that GIT_WORK_TREE
> points at without consulting $(pwd), so it is rather pointless.
> When the user switches to another worktree, both GIT_DIR and
> GIT_WORK_TREE need to be updated to point at appropriate places, so
> it sort of defeats the purpose.
>
> >
> >> C:\test\Local_Newfeature>git worktree list
> >> C:\GitRepo                (bare)
> >> C:/test/Local_Kumfeature  b0a097e [Local_Kumfeature_branch]
> >> C:/test/Local_Newfeature  b0a097e [Local_Newfeature_branch]
> >> C:/test/Local_SGSfeature  b0a097e [Local_SGSfeature_branch]
> >
> > I do not know whether it is a sane use-case to have a bare repository
> > and separate worktrees.
> >
> > Do not do that. Make a regular clone with a worktree and create
> > secondary worktrees from there.
>
> As long as GIT_DIR/GIT_WORK_TREE are both set and exported (or both
> unset, a new worktree made out of a bare clone should work just
> fine.  At least that is one of the use case I recall the feature was
> designed to be used in.
>
> Thanks.
>