search

jedbrown / git-fat

Simple way to handle fat files without committing them to git, supports synchronization using rsync
BSD 2-Clause "Simplified" License
621 stars 137 forks source link

git fat init after clone - already configured? #51

Closed kreuzberger closed 10 years ago

kreuzberger commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 9 years ago

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 commented 9 years ago

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 :-)