Re: [PATCH/WIP] completion: complete git diff with only changed files.

[Junio C Hamano <gitster@pobox.com>]

Paul Ebermann <Paul-Ebermann@gmx.de> writes:

> For me, it is not so much about saving CPU cycles (I have enough of
> these) but about not seeing things I don't want to see, and helping me
> decide what to type. This might be against the Git philosophy, I'm
> starting to realize.

I would say Git UI philosophy is it is justified to spend CPU cycles in
order to reduce brain cycles (of course it does not justify spending extra
CPU cycles for no gain), but your change cuts both ways. In the use case I
presented, it _wasted_ a dozen or so seconds of my brain cycle before I
get what I wanted to see. In your use case, it will reduce the need to
waste your brain cycle skiping the completion you would not want to see to
get to what you want. So I am not fundamentally opposed to the change, but
the trade-off will largely depend on what your workflow is and what system
you are on.

One thing that I am worried about is the latency before getting the list
of completion. I've heard enough horror stories on a filesystem with slow
lstat(3) even "diff-files --name-only" introduces a noticeable lag, so I
am not sure limiting this new codepath only to the case where you know the
comparison is made between the index and the working tree would save those
folks.

There already are existing knobs in the completion script to tweak how
much extra cycles the user is willing to spend to generate PS1. Perhaps
the new codepath can be made to trigger only to people who want it (or the
other way around, to allow people to disable)?