git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* inconsistent use of worktree?
@ 2007-09-06 13:29 martin f krafft
  2007-09-06 13:41 ` martin f krafft
  2007-09-15 15:23 ` inconsistent use of worktree? (resend) martin f krafft
  0 siblings, 2 replies; 3+ messages in thread
From: martin f krafft @ 2007-09-06 13:29 UTC (permalink / raw)
  To: git discussion list

[-- Attachment #1: Type: text/plain, Size: 3170 bytes --]

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.

So in a flash of utter genius, 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'

Huh, vimplate? What happened to the commit? Why vimplate?

  piper:~/.bin/colgit.git> git log
  commit 0ad26b00c31617bf3e31a052e3c3af9ef661407b
  Author: martin f. krafft <madduck@madduck.net>
  Date:   Thu Sep 6 11:45:38 2007 +0200

      repairing registration and other touchups

  [...]

But the commit appears alright, acd86b9 is the tip of ~/.git,
further up, and the output of git-rev-parse HEAD in ~/.bin, the
parent directory and worktree of ~/.bin/colgit.git.

What is git doing? Could it be that it's getting utterly confused
and inconsistently uses the worktree? I'd be happy to investigate
this, but want to make sure I am not doing anything wrong!

Cheers,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
"there are more things in heaven and earth, horatio,
 than are dreamt of in your philosophy."
                                                             -- hamlet
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: inconsistent use of worktree?
  2007-09-06 13:29 inconsistent use of worktree? martin f krafft
@ 2007-09-06 13:41 ` martin f krafft
  2007-09-15 15:23 ` inconsistent use of worktree? (resend) martin f krafft
  1 sibling, 0 replies; 3+ messages in thread
From: martin f krafft @ 2007-09-06 13:41 UTC (permalink / raw)
  To: git discussion list

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

also sprach martin f krafft <madduck@madduck.net> [2007.09.06.1529 +0200]:
> What is git doing? Could it be that it's getting utterly confused
> and inconsistently uses the worktree? I'd be happy to investigate
> this, but want to make sure I am not doing anything wrong!

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

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
redistribution of this email via the
microsoft network is prohibited.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* inconsistent use of worktree? (resend)
  2007-09-06 13:29 inconsistent use of worktree? martin f krafft
  2007-09-06 13:41 ` martin f krafft
@ 2007-09-15 15:23 ` martin f krafft
  1 sibling, 0 replies; 3+ messages in thread
From: martin f krafft @ 2007-09-15 15:23 UTC (permalink / raw)
  To: git discussion list; +Cc: matled, Johannes.Schindelin

[-- Attachment #1: Type: text/plain, Size: 4064 bytes --]

[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

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-09-15 15:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-06 13:29 inconsistent use of worktree? martin f krafft
2007-09-06 13:41 ` martin f krafft
2007-09-15 15:23 ` inconsistent use of worktree? (resend) martin f krafft

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).