[this message received no replies, I thus resend once with Matthias
and Johannes on Cc, and slightly modified]

Hi there,

I have a $GIT_DIR in ~/.bin/colgit.git, which is bare=false and has
worktree=.. (the parent). This relates back to a suggestion by
Johannes Schindelin [0] for maintaining files like ~/.vimrc and
~/.zshrc in separate repos sharing the same worktree. In short:
while ~/.bin/colgit.git holds all of colgit's objects, refs, and the
index, the repository's files are in ~/.bin (and thus in $PATH).

0. http://marc.info/?l=git&m=118418927823760&w=2

I am trying to figure out a sensible way to work with this, ideally
one which does not require me to set $GIT_DIR (which works):

  GIT_DIR=~/.bin/colgit.git git status
  GIT_DIR=~/.bin/colgit.git git add ...
  GIT_DIR=~/.bin/colgit.git git commit ...
  (or one export GIT_DIR)

but that's a lot of typing and thus error-prone.

I found this to work:

  piper:~/.bin/colgit.git> git status
  # On branch master
  # Changed but not updated:
  #   (use "git add <file>..." to update what will be committed)
  #
  #       modified:   colgit
  #
  no changes added to commit (use "git add" and/or "git commit -a")

  piper:~/.bin/colgit.git> git add ../colgit

  piper:~/.bin/colgit.git> git status
  # On branch master
  # Changes to be committed:
  #   (use "git reset HEAD <file>..." to unstage)
  #
  #       modified:   colgit

and I rejoiced, because that's really pretty cool. But then, trying
to commit, reality hit back:

  piper:~/.bin/colgit.git> git commit -m'initial commit'
  nothing to commit (use "git add file1 file2" to include for commit)

So I had to revert to using GIT_DIR for this:

  piper:~/.bin> GIT_DIR=colgit.git git commit -m'initial commit'
  Created initial commit 008594d: initial commit
   1 files changed, 104 insertions(+), 0 deletions(-)
   create mode 100755 colgit

And then things got really weird, after I accidentally tried the
direct commit (without GIT_DIR) again, following some touchups
I made to the colgit file:

  piper:~/.bin/colgit.git> git commit -m'repairing registration and other touchups'
  Created commit acd86b9: Merge branch 'vimplate'

First, it seems that commits work just fine for changes made only to
files already tracked by git, but not if a commit introduces a new
file.

But second, git-commit does appear to get really confused, since
the commit it claims to have just created is actually not part of
the current repository, but rather the HEAD of the repository in
~/.git (which tracks ~).

git-commit -a also does not work:

  piper:~/.bin/colgit.git> git commit -m'add list action to enumerate all known repos' -a
  error: .bin/colgit: cannot add to the index - missing --add option?
  fatal: Unable to process path .bin/colgit

And finally, git-diff seems to think that I removed the file, rather
than to show differences:

piper:~/.bin/colgit.git> git diff | diffstat                                                    #[334]
 colgit |  138 -----------------------------------------------------------------
 1 file changed, 138 deletions(-)

When in fact:

piper:~/.bin> GIT_DIR=colgit.git git diff | diffstat                                            #[342]
 colgit |    1 +
 1 file changed, 1 insertion(+)

It seems to me that worktree support is still somewhat buggy. Has
anyone experienced similar things? Does anyone have an idea what
this could be about?

I hope to be able to go through the code in the near future but
I first have to learn a lot about git innards, so this could take
a while. Maybe Matthias has a clue? I'd be happy yo test.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
"i wish there was a knob on the tv to turn up the intelligence.
 there's a knob called 'brightness', but it doesn't seem to work."
                                                          -- gallagher
 
spamtraps: madduck.bogus@madduck.net