Re: [PATCH v2] git-prompt: show presence of unresolved conflicts at command prompt

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

Phillip Wood <phillip.wood123@gmail.com> 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.