Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > I had not commented as I don't use the prompt. I have just had a quick > read and I wonder if it would be more efficient to use > git diff --cached --quiet --diff-filter=U > rather than > git ls-files --unmerged 2>/dev/null > to check if there are unmerged entries, The former reads the on-disk index into in-core index, and reads tree objects (recursively for subdirectories) referenced by the HEAD, walks both in parallel to find differences and filters out the result to unmerged (I am not sure how well diff-filter works with unmerged paths, though). The latter rads the on-disk index into in-core index, scans the entries and finds unmerged entries. So if we compare the overhead to run either command standalone, I am reasonably sure that the latter would be a lot more efficient. But if the shell prompt code already needs to run the diff-index for other reasons (e.g. to show if there is any modification added to the index), that may change the equation. Instead of adding a separate and extra call to "ls-files -u", it might be more efficient if you can somehow piggy-back on an existing diff-index call. For example, you may be running "git diff --cached --quiet" for exit code to show if any change has been added, but you can instead run "git diff --no-ext-diff --no-renames --cached --name-status" and (1) if there is any output, then the index is dirty, and (2) if there is a line that begins with "U", you have an unmerged path right there.
