git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Lederhofer <matled@gmx.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: finding the right remote branch for a commit
Date: Mon, 16 Jul 2007 00:33:41 +0200	[thread overview]
Message-ID: <20070715223341.GA3797@moooo.ath.cx> (raw)
In-Reply-To: <Pine.LNX.4.64.0707112226170.4516@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

  parent reply	other threads:[~2007-07-15 22:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-10 14:49 finding the right remote branch for a commit martin f krafft
2007-07-11 21:26 ` Johannes Schindelin
2007-07-12  7:47   ` martin f krafft
2007-07-12  9:33     ` Jakub Narebski
2007-07-15 22:33   ` Matthias Lederhofer [this message]
2007-07-15 23:48     ` Johannes Schindelin
2007-07-16  9:14       ` Matthias Lederhofer

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=20070715223341.GA3797@moooo.ath.cx \
    --to=matled@gmx.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).