Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> In practice, and I consider these all bugs, it does not work:
>
> - you have to say
>
> $ git --work-tree=$HOME --bare init
>
> which is a bit counterintuitive. After all, it is _not_ a bare
> repository. The whole purpose of worktree, as far as I understand, is
> to have a _detached_ repository, which would otherwise be called bare.
Use
$ git --work-tree "$HOME" --git-dir . init
instead.
IMHO the --bare flag did not make much sense before the introduction
of GIT_WORK_TREE and doesn't after, at least not with the meaning it
has: why should 'git --bare' mean to use the repository from cwd?
Ok, git --bare implies that you cannot use a working tree because
you're at the top of the git repository directory which may not be
used as working tree.
Now bare only means that some protection mechanisms are disabled and
some default values change (i.e. overwrite HEAD, enable/disable
reflogs by default). So maybe the name bare itself is a bit
counterintuitive now.
> - $ git status
>
> does not do what you would expect: it fails, telling you that it needs a
> work tree, of all things. You can say (tongue-in-cheek)
>
> $ (export GIT_DIR="$(pwd)" && cd "$(git config core.worktree)" &&
> git status)
>
> So, git knows about the location of the working tree, but just ignores
> that.
>
> - In the case that you forget to set GIT_DIR, you better not have any
> .git/ repository in $HOME/ or $HOME/gits/, because it will pick up that
> instead! Even if you are _inside_ a detached git directory!
>
> So you better not try some games like this in a subdirectory of your
> local git.git repository. It is a fine way to get completely confused.
> And certainly do _not_ do something like "git reset --hard <branch>"
> there.
>
> - Of course, it would be nice if something like that worked:
>
> $ cd $HOME/gits/vim.git
> $ git add $HOME/.vimrc
>
> But it does not work, because it wants to _be_ in the work tree. Of
> course, you have to specify the GIT_DIR again, because the working tree
> does not know about the location of the repository, but vice versa.
Up to now you are supposed to be in the working tree all the time when
using it. Therefore I'd call these feature requests rather than bugs :)
For git status it should be quite easy to add a special case to change
to the top of the working tree as long as no paths are used as
parameters.
When paths are used (either with git status or git add) you'd have to
translate the specified path to a path relative to the working tree.
This should be possible with chdir, getcwd and prefixcmp. If this
gets implemented for git status/git add it should probably get
implemented for all commands for which it makes sense. I think this
would be nice to have but I'm not sure how complicated this is to
implement.
-
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
