From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: martin f krafft <madduck@madduck.net>
Cc: git discussion list <git@vger.kernel.org>,
Matthias Lederhofer <matled@gmx.net>
Subject: Re: finding the right remote branch for a commit
Date: Wed, 11 Jul 2007 22:26:23 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0707112226170.4516@racer.site> (raw)
In-Reply-To: <20070710144907.GA324@piper.oerlikon.madduck.net>
Hi,
On Tue, 10 Jul 2007, martin f krafft wrote:
> I am trying to figure out a way to store ~/.etc in git. With SVN,
> I would have a .etc repository for each machine, which would use
> svn:externals to reference locations of the various subdirectories,
> which SVN would then pull and assemble. Thus, my ~/.etc might be
>
> ~/.etc
> ~/.etc/ssh [svn+ssh://svn.madduck.net/priv/etc/ssh]
> ~/.etc/vim [svn+ssh://svn.madduck.net/pub/etc/vim]
> ...
>
> [...]
>
> Thus, the vim repository might look like this:
>
> .etc/
> |-- vim/
> | `-- rc.vim
> `-- .vimrc -> .etc/vim/rc.vim
>
> and the ssh configuration might be
>
> .etc/
> |-- ssh/
> | |-- config
> | `-- authorized_keys
> `-- .ssh -> .etc/ssh/
Okay, after discussing this for a bit on IRC, here is what I would do (I
already said this on IRC, but the mailing list is really the better medium
for this):
I would actually rename .etc/ into gits/, because it is not a directory
containing settings, but a directory containing repositories.
Then I would create bare repositories gits/vim.git/, gits/ssh.git/,
gits/mutt.git/, etc. but as soon as I created them, I would make them
"unbare", i.e. "git config core.bare false".
Everytime I would work on, say, .vimrc, I would say
"--git-dir=$HOME/gits/vim.git", or maybe even make an alias in
$HOME/.gitconfig, which spares me that:
$ git config --global vim '!git --git-dir=$HOME/gits/vim.git'
Then I could see the status with
$ git vim status
Come to think of it, this is maybe what I would have done, but it appears
to me that this is the _ideal_ use case for worktree:
In $HOME/gits:
$ mkdir vim.git && cd vim.git
$ git --work-tree=$HOME init
$ cat >> info/exclude < EOF
*
!/.vimrc
EOF
Then you could do all Git operations like push, fetch, pull, log in
$HOME/gits/vim.git, and all editing in $HOME.
At least that is the theory.
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.
- $ 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.
Those are serious bugs. Matthias, any idea how to fix them?
Ciao,
Dscho
next prev parent reply other threads:[~2007-07-11 21:27 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 [this message]
2007-07-12 7:47 ` martin f krafft
2007-07-12 9:33 ` Jakub Narebski
2007-07-15 22:33 ` Matthias Lederhofer
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=Pine.LNX.4.64.0707112226170.4516@racer.site \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=madduck@madduck.net \
--cc=matled@gmx.net \
/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).