git fat init after clone - already configured?

[kreuzberger]

Hi!
i am currently evaluating git-fat for usage.

i follow your readme and was able to add files via git-fat into my remote rsync-location with git fat push

i clone the repository.
git clone /home/jkr/src/testing_git
Klone nach 'testing_git'...
Fertig.
Usage: git fat [init|status|push|pull|gc|verify|checkout|find|index-filter]
Usage: git fat [init|status|push|pull|gc|verify|checkout|find|index-filter]

First question: something triggered git fat actions, but what?
Second question: if i now make a git fat init, it says:
Git fat already configured, check configuration in .git/config

but .git/config seems not to have any git fat entries?
.git/fat/objects is empty

the fat files (two jpeg files) are of size 0 (expecting file content with hash?)
git fat status shows
Orphan objects:
f07b6a730094a122e32677b4c2b187020ed4c491
64dfd7dfa562b4e0b673d538cfb43c4d0bad36fe
exactly the files i am missing
git fat pull says:
receiving file list ...
0 files to consider

seems something in git clone went totaly wrong.

the original git repository has the required entries in .git/fat/objects.

Any help welcome :-)

[kreuzberger]

ok, the message comes cause i have set the filter settings globally in my --global scope like described in issue #43.

so focussing on this error is misleading. But why cant i read the files out with git fat pull. Should they have zero size?

[kreuzberger]

ok, got it working on linux and win with the script from #43.
(and only with it and rsync).
Unfortunatly, the fork and the master are heavily diverted, so it will take a while to integrate a pull-request. But i think its worth that :-)

[jedbrown]

Hmm, setting filters globally is not supported/tested, but perhaps it should be. Unfortunately, Python preferences for encoding are different from Git (always unencoded) and though my python3 branch worked fine on Linux, I never reached a satisfactory solution for Windows. I don't know whether it's the case with the fork you mention, but many of the forks out there have compromised backward compatibility, thus preventing their merge to 'master'. This can be somewhat confusing.

[kreuzberger]

With the fork i mentionend (from issue #43) i had no problems on windows and linux, but for sure i have not to consider any backwards compatibility. On windows i used python 2.7.

Interesting for me is only the rsync part, which did not worked even on linux with your "trunk" version. Therefore i have to identify the changes made for rsync and find out how to merge them into your trunk version. Will see if i have any success :-)