git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sivanandan Srilakshmanan <ssrilaks@gmail.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Pratyush Yadav <me@yadavpratyush.com>, git@vger.kernel.org
Subject: Re: working directory status
Date: Mon, 18 Nov 2019 15:32:32 +1100	[thread overview]
Message-ID: <CACKP9csUwnYJFL55KSMmys+o7FC5Wzds_2kbCcYNESiL-SES1A@mail.gmail.com> (raw)
In-Reply-To: <6bb36048-6649-ebe3-062f-c5564f7d4ec4@kdbg.org>

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

  reply	other threads:[~2019-11-18  4:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-17  0:55 working directory status Sivanandan Srilakshmanan
2019-11-17  7:29 ` Pratyush Yadav
2019-11-17 11:07   ` Sivanandan Srilakshmanan
2019-11-17 12:30     ` Johannes Sixt
2019-11-17 20:33       ` Sivanandan Srilakshmanan
2019-11-17 22:26         ` Johannes Sixt
2019-11-18  4:32           ` Sivanandan Srilakshmanan [this message]
2019-11-18  6:51             ` Johannes Sixt
2019-11-18  7:01               ` Eric Sunshine
2019-11-18  7:12           ` Junio C Hamano
2019-11-18 10:40             ` Sivanandan Srilakshmanan

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=CACKP9csUwnYJFL55KSMmys+o7FC5Wzds_2kbCcYNESiL-SES1A@mail.gmail.com \
    --to=ssrilaks@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=me@yadavpratyush.com \
    /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).