-
Notifications
You must be signed in to change notification settings - Fork 137
Big refactor, API incompatible changes #19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
New filter smudge uses new decode function. Updated can_add_file to use new decode function and removed hash-object/cat-file in favor of just checking the most immediately previous revision.
list_files will list the path and git-fat hash for the files.
Also added comments on some of the more complex pieces of code.
Since the modified time on file stat only has a granularity of 1s, updating the modified time wasn't good enough to resmudge. (e.g. clone and fat pull within one second). See inline comments for more detail.
When calling os.wait() without reading stdout, the PIPE buffers fill up and can't be written to. Since the subprocess never ends (since it's not done writing) wait will never return and a deadlock is encountered. To solve this, we simply read the stdout of the process
These were caused by trying to read stdout when nothing was written to it by git show.
Newbie mistake. However, it's fixed and a test was added for it.
StopIteration was raised when it shouldn't be under the condition that there were files in the repository that matched the filter but which were also 0 bytes length.
I meant to do this in the last one, but forgot until after I sdist uploaded.
I added a note referencing this pull request in the pypi package in the hopes that people are less confused. |
> The operation may fail on some Unix flavors if src and dst are on > different filesystems https://docs.python.org/2/library/os.html#os.rename
The pylint warning below was added in pylint 1.4. > [W1202]:logging-format-interpolation: Use % formatting in logging > functions but pass the % parameters as arguments However, it's not really applicable to git-fat since we don't use old style formatting (which is all the logging module supports) More info: http://stackoverflow.com/questions/12843099/python-logging-typeerror-not-all-arguments-converted-during-string-formatting
Fixed issues with logging. The test_git_fat_no_dotgitfat test was failing. Also there were problems with seeing log messages on Windows. Always use logger.xxx() functions instead of the logging.xxx(). Improvements to logging. Introduced the GIT_FAT_LOG_LEVEL and GIT_FAT_LOG_FILE environment variables to ease debugging. Also improved error detection in unit tests. Some of the errors may be thrown by sub-subprocesses and the only way to catch them is to check the log file for errors. This will catch problems like the one reported in Issue #30. Fixed 'Permission denied' issues when moving or deleting files on Windows. Always use the new functions move_file() and delete_file() when renaming or deleting file. In unit tests also fixed a 'Access is denied' issue when deleting the temp git repository directory. On Linux files are opened in binary mode by default. But on Windows the text mode is the default. Always specify "rb" or "wb" mode when opening files for reading/writing. Additionaly it was also required to change mode to binary for sys.stdin and sys.stdout. On Windows rsync/awk tools are not available. It is required to ship these tools. It is also required to ship a custom ssh executable that works with rsync. These dependencies are included in the Python Wheel binary package. Use the win32/setup_wheel.bat to create a .whl package. This package can be be uploaded to PyPI so that the pip package manager can be used to install git-fat on Windows. Fixed issues with deleting files that had been previously opened for reading (and not closed). On Linux such code works fine, but on Windows it throws exceptions. Avoid code such as this: with open(fname) as f: if get_digest(fname): delete_file(fname) Fixed error when executing command "git fat". A help should appear, but instead an error was thrown. Fixed issue when git init.templatedir option is set (Issue #30). Before running each test this option is unset and restored after the test was completed. The FileTypeTestCase.test_symlink_74bytes() won't be run on Windows, as symbolic links are not supported by git on Windows. Fixed issue with temp files not being deleted in the GeneralTestCase.test_index_filter() test.
Support for Windows.
rsync: fix command to handle spaces
Currently, it only supports passwordless rsyncd shares, since this is what I use here. I can add user / pass parameters if there is demand for it.
Add support for rsyncd shares to the rsync backend
…nt checkout automatically
Fixed bug in CopyBackend that prevented git fat pull running subsequent ...
resolves #43 to improve the performance when pulling large amount of bin...
First, allow pulling individual files with the following syntax: $ git fat pull foo.png bar.png bat.png $ git fat pull rsync foo.png bar.png bat.png Second, use GIT_SSH for rsync transport. If the user has configured git to use a particular ssh command by setting the environment variable `GIT_SSH`, then use that command as the rsync shell. See also git's documentation on this environment variable: http://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#Miscellaneous
Support partial pulls and respect GIT_SSH
We should really have a CI be running these. :-)
resolves #49 to make 'git fat pull' compatible with a sparse-checkout re...
Turns out that checkout-index can acutally be passed multiple paths (like most git commands). This should give the same performance increase as before but without needing an extra argument and including the benefit for everyone else. Thanks @demonyangyue!
I see there was a release on PyPi all the way to There is a plan to consolidate and bring all the cool stuff into the fold with the blessing of @jedbrown or you guys have different plans? Best and thanks for this neat module |
Hi @mattions I've actually been lacking the time to properly maintain the cyaninc fork unfortunately. I'm not sure what would have been needed to get it back into the mainline here, but I think it'll probably just sit the way it is. |
At this point, the projects have diverged enough that it doesn't really make sense for them to keep using the same name. @jedbrown - What do you think? |
@ahmadia It appears that neither @abraithwaite nor myself have time to integrate the two forks in the near future. In that case, I think it's important to communicate to users that the two forks are not compatible. Names are the most common way to do that, but at this point would require a name change that may be even more confusing to users, thus I don't have a strong preference. |
Hey @jedbrown, we've been using
git-fat
at our company and we love it!We've made a load of changes to suit our needs and some of those changes make it incompatible with yours.
I've also packaged it as a pypi package to make it easy to install (although it has no real usefulness as a module alone).
I don't expect you to merge it because of the API changes, but we wanted to let you know that we love what you've done and to give back what changes we made.