All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Karsten Blees <karsten.blees@gmail.com>,
	Dennis Kaarsemaker <dennis@kaarsemaker.net>,
	git@vger.kernel.org, ingy@ingy.net
Subject: Re: [PATCH] path_treatment: also ignore $GIT_DIR if it's not .git
Date: Tue, 3 Dec 2013 11:07:15 -0800	[thread overview]
Message-ID: <20131203190715.GC29959@google.com> (raw)
In-Reply-To: <xmqqtxepokej.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:
> Karsten Blees <karsten.blees@gmail.com> writes:

>> If we don't want to support this, though, I think it would be more
>> approrpiate to issue a warning if GIT_DIR points to a worktree
>> location.
>
> But how do tell what is and isn't a "worktree location"?  Having the
> path in the index would be one, but you may find it out only after
> issuing "git checkout $antient_commit".

I think the idea was that *any* path under $(git rev-parse
--show-toplevel) would not be a valid GIT_DIR, unless its last path
component is ".git".

Alas, I don't think that would work smoothly.

 - Some people may already be using GIT_DIR=$HOME/dotfiles.git to
   track some files with a toplevel of $HOME.  That is error-prone and
   it would be cleaner to either use plain .git or keep the $GIT_DIR
   outside the worktree (for example by tucking dotfiles into a
   separate $HOME/dotfiles dir), true, but producing a noisy warning
   with no way out would not serve these people well.

 - There is no outside-the-worktree location when GIT_WORK_TREE=/.

So your suggestion of at least noticing when "git checkout" wants to
write files that overlap with the GIT_DIR seems simpler.

      parent reply	other threads:[~2013-12-03 19:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-01  7:06 GIT_DIR not auto ignored Ingy dot Net
2013-12-01 18:08 ` Dennis Kaarsemaker
2013-12-01 18:30   ` Dennis Kaarsemaker
2013-12-01 19:04     ` [PATCH] path_treatment: also ignore $GIT_DIR if it's not .git Dennis Kaarsemaker
2013-12-01 23:02       ` Duy Nguyen
2013-12-01 23:08         ` Thomas Rast
2013-12-01 23:38           ` Dennis Kaarsemaker
2013-12-02  0:38             ` Duy Nguyen
2013-12-02  8:01               ` Dennis Kaarsemaker
2013-12-02  9:35                 ` Duy Nguyen
2013-12-02 11:40                   ` Dennis Kaarsemaker
2013-12-02 12:01                     ` Duy Nguyen
2013-12-02  1:21       ` Eric Sunshine
2013-12-03 15:18       ` Karsten Blees
2013-12-03 18:32         ` Junio C Hamano
2013-12-03 19:00           ` Karsten Blees
2013-12-03 19:07           ` Jonathan Nieder [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=20131203190715.GC29959@google.com \
    --to=jrnieder@gmail.com \
    --cc=dennis@kaarsemaker.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ingy@ingy.net \
    --cc=karsten.blees@gmail.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 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.