Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line

[Sebastian Thiel <byronimo@gmail.com>]

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