git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sivanandan Srilakshmanan <ssrilaks@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
	Pratyush Yadav <me@yadavpratyush.com>,
	git@vger.kernel.org, sunshine@sunshineco.com
Subject: Re: working directory status
Date: Mon, 18 Nov 2019 21:40:22 +1100	[thread overview]
Message-ID: <CACKP9ct0AJE94=C32QEH_uD8S8PdGoFeW15oftcf-wifh6hWLA@mail.gmail.com> (raw)
In-Reply-To: <xmqqk17x1wvx.fsf@gitster-ct.c.googlers.com>

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

      reply	other threads:[~2019-11-18 10:40 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
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 [this message]

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='CACKP9ct0AJE94=C32QEH_uD8S8PdGoFeW15oftcf-wifh6hWLA@mail.gmail.com' \
    --to=ssrilaks@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=me@yadavpratyush.com \
    --cc=sunshine@sunshineco.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).