Paul Ebermann <Paul-Ebermann@xxxxxx> 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)? -- 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