I was under the impression that git commands which affect repository (as
opposed to the local file system) work from any subdirectory inside the
repository. For example:
[b04825@efes linux.cq-test]$ git log -1
commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
Author: Timur Tabi [off-list ref]
Date: Wed Oct 31 15:56:20 2012 +0200
...
[b04825@efes linux.cq-test]$ cd .git
[b04825@efes .git]$ git log -1
commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
Author: Timur Tabi [off-list ref]
Date: Wed Oct 31 15:56:20 2012 +0200
...
It appears, however, that git-fetch does not work this way:
[b04825@efes linux.cq-test]$ git fetch upstream master
From ../linux-2.6
* branch master -> FETCH_HEAD
[b04825@efes linux.cq-test]$ cd .git
[b04825@efes .git]$ git fetch upstream master
fatal: '../linux-2.6.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
This makes it complicated because git hooks run from the .git directory on
normal repositories, but they run from the top-level directory on bare
repositories. Apparently, you need to be in the top-level directory for
git-fetch to run in any kind of repository.
--
Timur Tabi
Linux kernel developer at Freescale
Just a hunch but your remote's location uses a relative path
'../linux-2.6.git', perhaps git is messing up what the path is relative
to.
I assume this repo is beside the linux.cq-test repo? ie. perhaps
they're located at /home/user/git/linux.cq-test and
/home/user/git/linux-2.6.git.
Then, for example, from linux.cq-test it looks for
/home/user/git/linux-2.6.git but from linux.cq-test/.git it looks for
/home/user/git/linux.cq-test/linux-2.6.git, which is wrong.
Note sure what the fix will be though as it'll likely break existing
repositories that use relative paths either way. Can you try an
absolute path to see if that fixes thing?
Patrik
On Tue Nov 20 17:24:22 2012, Timur Tabi wrote:
I was under the impression that git commands which affect repository (as
opposed to the local file system) work from any subdirectory inside the
repository. For example:
[b04825@efes linux.cq-test]$ git log -1
commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
Author: Timur Tabi [off-list ref]
Date: Wed Oct 31 15:56:20 2012 +0200
...
[b04825@efes linux.cq-test]$ cd .git
[b04825@efes .git]$ git log -1
commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
Author: Timur Tabi [off-list ref]
Date: Wed Oct 31 15:56:20 2012 +0200
...
It appears, however, that git-fetch does not work this way:
[b04825@efes linux.cq-test]$ git fetch upstream master
From ../linux-2.6
* branch master -> FETCH_HEAD
[b04825@efes linux.cq-test]$ cd .git
[b04825@efes .git]$ git fetch upstream master
fatal: '../linux-2.6.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
This makes it complicated because git hooks run from the .git directory on
normal repositories, but they run from the top-level directory on bare
repositories. Apparently, you need to be in the top-level directory for
git-fetch to run in any kind of repository.
Patrik Gornicz wrote:
Just a hunch but your remote's location uses a relative path
'../linux-2.6.git', perhaps git is messing up what the path is relative
to.
That makes sense. Git is looking at the URL and not realizing that it's
relative to the home directory.
[remote "upstream"]
url = ../linux-2.6.git/
fetch = +refs/heads/*:refs/remotes/upstream/*
Note sure what the fix will be though as it'll likely break existing
repositories that use relative paths either way. Can you try an
absolute path to see if that fixes thing?
If I change that to
[remote "upstream"]
url = /home/b04825/git/linux-2.6.git/
fetch = +refs/heads/*:refs/remotes/upstream/*
then everything works.
IMHO, this is a bug in git.
--
Timur Tabi
Linux kernel developer at Freescale