Sorry for the badly formatted message, and thanks a lot for the correction which is what my post should have been in the first place. Redoing the commit is not what will be needed for git-python to work properly which is why I will tell the whole story before submitting any(more) patches. With git v1.6.5, git-push was adjusted not to provide progress messages anymore if the device attached to stderr is not a tty. Previously, this was only the case with git-fetch. For git-python, and other callers of the commandline such as tortoise-git, there currently is no way to provide progress information to the user unless they (somehow) simulate a tty which appears unfeasible. When using these tools, time consuming operations tend to appear as if they are hanging. One might argue that most code is fetched and pushed in a matter of seconds, but if git is used to store large binary data, processing and transferring it will take time. The issue mentioned with git-update-index and it's missing flush that would cause a deadlock in some porcelain can be fixed trivially, but seen in the context of the git-push and git-pull a more thorough solution might be more appealing. As mentioned by Junio, a default flush after each report might slow down some existing porcelain, and a commandline option would be part of the proper solution. I would argue though that a separate option would add quite some complexity to the command as it is a very specialized one. Instead I would recommend checking whether --stdin is given on the commandline, and flush stdout if that is true. This would natively make the command behave like git-hash-object and git-cat-file. If --stdin is not provided, report is not required to flush after every call as the commandline options are processed without additional user interaction. Adding a commandline option to git-push and git-pull that enforces progress messages to be printed to stderr would be a feasible and simple fix that would clearly improve the usability of tortoise-git and git-python to name only two. That said, I hope I managed to make myself clear enough this time to help the people in charge to figure out how to solve the issue. Once the desired solution has been sketched out and the desired new commandline options have been named, it could even be me to implement it if necessary, as I'd consider it a gentle start into the world of the git codebase. Thanks for picking this up again, Sebastian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html