Annoying absolute path for "core.worktree" to submodule

Hey folks,

I really love the work you are doing on GIT but the last update regarding submodules is a bit annoying. Although the path inside the ".git" file is stored relative to the submodule's path, the path in ".git/modules/path-to-submodule/config" is stored as an absolute path for "core.worktree".

I develop (for some projects) within a chroot where I have a different username and therefore the path differs if I am currently inside the chroot or not. If the submodule is initialized inside the chroot, I always get this message when I cd into the project's directory outside of the chroot:

fatal: Could not switch to '/home/chroot-username/parent-path-of-submodule': File or directory not found fatal: 'git status --porcelain' failed in submodule relative-path-to-submodule

This is caused by using `__git_ps1` for my bash-prompt. I don't know exactly where the problem is and what actions (called by __git_ps1) are responsible for this.

Any suggestions how to deal with this?

And no, removing __git_ps1 from my bash-prompt is not the answer, I like this feature very much. ;-)

Thanks in advance Christian

On 20/03/2012 9:52 am, Christian Hammerl wrote:

What are you referring to as the "last update"? v1.7.8 introduced the separate git dir for submodules, and used an absolute path.

This absolute path was changed to a relative path in the patchset at [1], which is present in v1.7.10-rc1.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/192173

path

Slightly off topic, but related, what is the recommended way for finding the git folder from the top level project or any of the submodules? And of finding the working tree from inside a hook script?

Context: One of the (optional) steps in our build process installs
pre-commit hooks into the git/hooks folder of the tools submodule and
into the git/hooks folder of the next level up project. Then on commit
the hook reads the config file from inside the tools submodule and
checks file formats and naming standards before permitting the commit.
The current implementation has the paths hard coded between the two
location, now with some having the old layout and some the new, we are
looking for a consistent solution without duplicating the logic in the
git executables.

Am 20.03.2012 22:39, schrieb Holding, Lawrence:

Run "git rev-parse --git-dir" inside the repo whose git folder you want to know.

I would expect hooks to be run in the work tree's top level directory, but I haven't checked that.

Ah ok, my current Version is 1.7.9.4. I did not recognize this behaviour before, so I assumed it came with the last update. Sorry for that.

I see, thanks for the information. I think I will wait until my linux distribution will update the package to 1.7.10. For now it works for me to replace the .git file with the corresponding repository which is located at ".git/modules/*" within the superproject.