All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enrico Weigelt <weigelt@metux.de>
To: git@vger.kernel.org
Subject: Re: [long] worktree setup cases
Date: Thu, 21 Oct 2010 21:01:47 +0200	[thread overview]
Message-ID: <20101021190146.GC28700@nibiru.local> (raw)
In-Reply-To: <7v8w1svate.fsf@alter.siamese.dyndns.org>

* Junio C Hamano <gitster@pobox.com> wrote:

> If you set GIT_DIR, we do no discovery, so git will work only from the
> root level of the working tree (or bare repository operation) if you do
> not tell us where the working tree is.

Well, we could look at config whether it's an non-bare repo and then
lookup worktree via core.worktree (which would default to "../").


BTW: the whole discovery process IMHO should start w/ looking for 
the gitdir. Could be done this way:

a) explicitly given (via GIT_DIR or --git-dir), take this one.
b) else: recursively scan for a valid .git dir from cwd upstairs to /

Once we've found gitdir, we can look for the worktree. Again:

a) explicitly given, then take it
b) bare repo: dont have any, bail out
c) non-bare repo: look up via core.worktree (w/ default to $GIT_DIR/../)
 
> Shouldn't all of these 16 be the same, if the repository is bare?  What is
> your definition of bareness?  core.bare?  In any case we should say "you
> are using a bare repository, there is no working tree" and cwd shouldn't
> change in these cases.  They are all bare and there is no working tree.

ACK. In a bare repo, the worktree lookup will fail per definition, so
worktree operations can only run with having it explicitly given.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

  parent reply	other threads:[~2010-10-21 19:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-20  8:59 [long] worktree setup cases Nguyen Thai Ngoc Duy
2010-10-20 19:07 ` Jonathan Nieder
2010-10-20 19:18   ` Jonathan Nieder
2010-10-21  1:46   ` Nguyen Thai Ngoc Duy
2010-10-21  3:30     ` Jonathan Nieder
2010-10-21 12:50       ` Nguyen Thai Ngoc Duy
2010-10-21 16:01         ` Jonathan Nieder
2010-10-23 10:12           ` Nguyen Thai Ngoc Duy
2010-10-21 18:51         ` Enrico Weigelt
2010-10-22  0:34           ` Nguyen Thai Ngoc Duy
2010-10-22  5:00             ` Enrico Weigelt
2010-10-22  5:28               ` .git file (Re: [long] worktree setup cases) Jonathan Nieder
2010-10-22  5:36               ` [long] worktree setup cases Nguyen Thai Ngoc Duy
2010-10-20 21:00 ` Junio C Hamano
2010-10-21  2:23   ` Nguyen Thai Ngoc Duy
2010-10-21 19:01   ` Enrico Weigelt [this message]
2010-10-21 23:06     ` Junio C Hamano

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=20101021190146.GC28700@nibiru.local \
    --to=weigelt@metux.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.