Re: [PATCH] git-init: set up GIT_DIR/workdir if GIT_WORK_DIR is set

Matthias Lederhofer [off-list ref] writes:

I just thought that GIT_WORK_DIR should be relative to the current
working directory because it's more intuitive, e.g.

    $ git --git-dir=/path/to/repo.git --work-dir=../.. add a

where ../.. matches the path to the toplevel working directory from
cwd.  But this definitely is annoying when changing directories.

Not so fast.  That was a trick suggestion, only meant to see if
you have thought through the issues, and you did not have to
agree with me so quickly ;-).  What I was pointing out was
merely that specifying the top as a path relative to the cwd in
permanent basis was not useful if you are going to cd around,
which is a tautology.

For a one-shot thing, I would agree that being able to say "I am
in Documentation/howto directory of the whole thing, so I can
name the top of my working tree as ../.." is far more useful and
natural than having to say "ehhhh, what is the top of the
working tree relative to my repository???".  If it is not a
one-shot thing and the user expects to cd around, then:

	$ GIT_WORK_DIR=$(pwd)/../..; export GIT_WORK_DIR
	$ git foo ...; git bar ...;

would be more natural, so I do not expect the semantics of
relative path would be a big issue in reality, as long as we
make it clear that it is relative to cwd.

By the way, I do not find your command line example intuitive at
all, whether the --work-dir= parameter is relative or absolute.
Do you honestry expect that loooong command line is something
people would use in real life?

With $GIT_DIR/workdir support, I would expect that people would
do (if what is done is only to add one file and nothing else):

	$ GIT_DIR=/path/to/repo.git git add a

And without $GIT_DIR/workdir support:

	$ GIT_DIR=/path/to/repo.git GIT_WORK_DIR=../.. git add a

If the user is going to work in the working tree for extended
period of time, cd'ing around and running multiple git commands:

	$ GIT_DIR=/path/to/repo.git; export GIT_DIR
        $ git foo ; git bar ; cd subdir ; git baz ; ...

And without $GIT_DIR/workdir support, perhaps the user would do:

	$ GIT_DIR=/path/to/repo.git; export GIT_DIR
	$ GIT_WORK_DIR=$(pwd)/../..; export GIT_WORK_DIR
        $ git foo ; git bar ; cd subdir ; git baz ; ...

What I am getting at is that I personally feel that --git-dir=
option is already an unnecessary redundancy that is there only
to confuse new people by having more than one way to do the same
thing, and --work-dir= option seems to be only adding to the
same confusion.  Do we really want that as an option?

Junio C Hamano [off-list ref] wrote:

Matthias Lederhofer [off-list ref] writes:

quoted

I just thought that GIT_WORK_DIR should be relative to the current
working directory because it's more intuitive, e.g.

    $ git --git-dir=/path/to/repo.git --work-dir=../.. add a

where ../.. matches the path to the toplevel working directory from
cwd.  But this definitely is annoying when changing directories.

Not so fast.  That was a trick suggestion, only meant to see if
you have thought through the issues, and you did not have to
agree with me so quickly ;-).

Well, I have no strong feelings for either handling because I'll
probably always use `pwd`/relative/path anyway.

Is there anything more to this decision than this?

GIT_WORK_DIR relative to cwd:
    git --work-dir <path> [..] is more intuitive

GIT_WORK_DIR relative to $GIT_DIR:
    $GIT_DIR/workdir and $GIT_WORK_DIR are interpreted exactly the
    same way, which primarily makes it easier to implement git init
    with --work-dir :-)

By the way, I do not find your command line example intuitive at
all, whether the --work-dir= parameter is relative or absolute.
Do you honestry expect that loooong command line is something
people would use in real life?

For one-shot things I prefer --git-dir and --work-dir over
GIT_DIR and GIT_WORK_DIR because they are lowercase and for
GIT_WORK_DIR it's even shorter; and all the examples were one-shot
things (well, one used the same --git-dir twice).