Re: [PATCH] allow setting GIT_WORK_TREE to "no work tree"

Junio C Hamano [off-list ref] writes:

quoted

The other option is setting

  GIT_MAGICALLY_SET_GIT_DIR_SO_DONT_ACT_LIKE_THE_USER_DID=1

but I was hoping to avoid that.

Yuck.  Let's then try your original (slightly redundant) one.

Oops, scratch that.  I was confused.

I do not like the magic GIT_WORK_TREE=: which is simply
illogical.  GIT_EDITOR=: made perfect sense (":" is actually a
command that succeeds without doing anything), but ":" does not
have anything to do with "there is no such path".

I was tempted to suggest GIT_WORK_TREE=/dev/null because that is
what "diff" uses to mark "this does not even exist", but that
feels dirty.

On Wed, Feb 06, 2008 at 12:59:32PM -0800, Junio C Hamano wrote:

I do not like the magic GIT_WORK_TREE=: which is simply
illogical.  GIT_EDITOR=: made perfect sense (":" is actually a
command that succeeds without doing anything), but ":" does not
have anything to do with "there is no such path".

No, it doesn't, but they are both no-ops. Sort of. I agree the reasoning
is stretched, but I think we are just going to have to choose _some_
arbitrary value.

Unless you want to switch it to a "git set GIT_DIR automatically,
so don't pretend the user set it" flag variable.

I was tempted to suggest GIT_WORK_TREE=/dev/null because that is
what "diff" uses to mark "this does not even exist", but that
feels dirty.

It feels dirty to me, too. I would rather choose something that doesn't
even look like a path. I think GIT_WORK_TREE=" " is too ugly, too.

Also, having just looked at the '.git-file' code, it does the same thing
(setting GIT_DIR even though the user didn't explicitly ask for it), so
it will need a similar fix. Which makes me lean towards just setting a
"we set this behind the user's back" flag, since that code won't even
have anything to do with the worktree.

In fact, the more I think about it, that makes sense. WORK_TREE munging
just happens to be the only special behavior right now that depends on
whether the user manually set GIT_DIR. But what we really want to
communicate to later code is not "I have corrected this particular
munge" but "don't run any special behavior as a result of this variable
being set."

-Peff

On Feb 7, 2008 12:13 AM, Jeff King [off-list ref] wrote:

On Wed, Feb 06, 2008 at 12:59:32PM -0800, Junio C Hamano wrote:

quoted

I was tempted to suggest GIT_WORK_TREE=/dev/null because that is
what "diff" uses to mark "this does not even exist", but that
feels dirty.

It feels dirty to me, too. I would rather choose something that doesn't
even look like a path. I think GIT_WORK_TREE=" " is too ugly, too.

Is using something like "__GIT_WORK_TREE_NOT_SET__" that terrible?

j.

Jeff King [off-list ref] writes:

In fact, the more I think about it, that makes sense. WORK_TREE munging
just happens to be the only special behavior right now that depends on
whether the user manually set GIT_DIR. But what we really want to
communicate to later code is not "I have corrected this particular
munge" but "don't run any special behavior as a result of this variable
being set."

Yeah, that makes sense.

Hi,

On Thu, 7 Feb 2008, Jay Soffian wrote:

On Feb 7, 2008 12:13 AM, Jeff King [off-list ref] wrote:

quoted

On Wed, Feb 06, 2008 at 12:59:32PM -0800, Junio C Hamano wrote:

quoted

I was tempted to suggest GIT_WORK_TREE=/dev/null because that is
what "diff" uses to mark "this does not even exist", but that
feels dirty.

It feels dirty to me, too. I would rather choose something that doesn't
even look like a path. I think GIT_WORK_TREE=" " is too ugly, too.

Is using something like "__GIT_WORK_TREE_NOT_SET__" that terrible?

Yes.  First: it looks more like a C constant than a proper environment 
variable.  Second: what to do _sanely_, when both GIT_WORK_TREE and 
GIT_WORK_TREE_NOT_SET are true?

Of course, you could argue that one should override the other.  But the 
consequence will be user errors that could be prevented, thus it is a 
design error.

Ciao,
Dscho

On Feb 7, 2008 7:33 AM, Johannes Schindelin [off-list ref] wrote:

On Thu, 7 Feb 2008, Jay Soffian wrote:

quoted

Is using something like "__GIT_WORK_TREE_NOT_SET__" that terrible?

Yes.  First: it looks more like a C constant than a proper environment
variable.  Second: what to do _sanely_, when both GIT_WORK_TREE and
GIT_WORK_TREE_NOT_SET are true?

Sorry I was unclear. The discussion was about using a special value to
denote "this is not set." So I meant something like:

GIT_WORK_TREE="__GIT_WORK_TREE_NOT_SET"

There may not be precedent in git, but it is not unusual to use a
double-underbar prefix to denote private names and/or values. While in
theory a user could have a directory named as such, it would seem
highly unlikely. This looks a little cleaner to me than using ":", "
", or "/dev/null".

j.