git and filesystem problems (ext3 and vfat)

Hello, ]

 I have a diskOnKey which has a vfat filesystem.
I ran there:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
the I copied all the wireless-2.6 folder to an ext3 partition.
There I ran git diff.

I get many messages like these (probably on all files of the repository):

diff --git a/COPYING b/COPYING
deleted file mode 100644
index ca442d3..0000000
--- a/COPYING
+++ /dev/null

@@ -1,356 +0,0 @@
-

and then all the lines of the file with "-" in the beginning, as if
they are empty.

Why is it so ?
Is there any way to overcome it ?
Must I run "git clone" on an ext3 DiskOnKey only ?

Regards,
Ian

Ian Brown venit, vidit, dixit 16.10.2008 18:03:

Hello, ]

 I have a diskOnKey which has a vfat filesystem.
I ran there:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
the I copied all the wireless-2.6 folder to an ext3 partition.

How did you copy it?

git diff gives you the difference between the index and the work tree.
The index is the one you copied from vfat; git doesn't see the files on
the ext3 work tree. Do you see them with ls?

One by one I would try

git status
git reset
git reset --hard

in order to reconcile your index with your checkout. You probably need
the last one.

Michael

On Thu, Oct 16, 2008 at 5:03 PM, Ian Brown [off-list ref] wrote:

The first question is what do the directories on the vfat and ext3
disks look like? Are the files like COPYING present in both directory
trees (so git is wrong at that point of the diff) or has something
gone wrong earlier?

Why is it so ?
Is there any way to overcome it ?
Must I run "git clone" on an ext3 DiskOnKey only ?

I have certainly cloned onto a vfat partition with no problems,
although I've always done it with a --bare clone because a lot of my
repos have had case sensitive filenames and I've had some problems
with the "git dirent reading code reads back different case file names
than it wrote out and gets confused". If you're only transporting the
repo on the stick, I'd definitely do it via "git clone --bare" just to
reduce the potential for problems.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot

Hello,
Thanks for you quick answer.

ls shows the files.

git status shows:
fatal: Not a git repository
Regards,
IB

On Thu, Oct 16, 2008 at 6:17 PM, Michael J Gruber
[off-list ref] wrote:

Ian Brown venit, vidit, dixit 16.10.2008 18:03:

quoted

Hello, ]

 I have a diskOnKey which has a vfat filesystem.
I ran there:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
the I copied all the wireless-2.6 folder to an ext3 partition.

How did you copy it?

quoted

There I ran git diff.

I get many messages like these (probably on all files of the repository):

diff --git a/COPYING b/COPYING
deleted file mode 100644
index ca442d3..0000000
--- a/COPYING
+++ /dev/null

@@ -1,356 +0,0 @@
-

and then all the lines of the file with "-" in the beginning, as if
they are empty.

Why is it so ?
Is there any way to overcome it ?
Must I run "git clone" on an ext3 DiskOnKey only ?

git diff gives you the difference between the index and the work tree.
The index is the one you copied from vfat; git doesn't see the files on
the ext3 work tree. Do you see them with ls?

One by one I would try

git status
git reset
git reset --hard

in order to reconcile your index with your checkout. You probably need
the last one.

Michael

On Thu, Oct 16, 2008 at 5:23 PM, Ian Brown [off-list ref] wrote:

Hello,
Thanks for you quick answer.

ls shows the files.

I'm assuming this is on both the vfat and ext3 disks? All the
filenames' cases are correct?

git status shows:
fatal: Not a git repository
Regards,
IB

The error message unfortunately really means "git couldn't find
_everything_ needed to be a repository" without saying what precisely
it had problems finding. Educated guess: Have a look in the .git
directory on each disk. Is there a file called 'HEAD' or has its case
been changed?

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot