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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux