Re: how to automatically open conflicted files when "git rebase" encounter conflict

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

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> Fortunately, there are lots of ways to do this.  The way I happen to do
> it is with an alias:
>
>   [alias]
>     conflicted = "!f() { git status -s | grep -E '^(DD|AA|.U|U.)' | cut -b4-; };f"
>
> and then I run this:
>
>   git conflicted | xargs nvim-gtk
>
> To preempt someone pointing this out, you would want to use "git status
> --porcelain" for scripting instead of "git status -s", but I happen to
> know what I'm doing in this particular case (and have reasons for it)
> and can fix things if it breaks.  You should probably use --porcelain.

I wonder if adding "--name-only" support to "ls-files" helps here.
It would make the above

    git ls-files [-z] --name-only -u | xargs [-0] editor

As your "grep -E" pattern indicates, "status" makes another
comparison with HEAD that we do not even use, when we only need to
list the unmerged paths in the index.

There is no "--[no-]name-only", and "-s" (for obvious reasons) asks
to show the mode, stage, and the object name information.  When we
added "-u", we said "if you are asking for conflicted paths, you of
course want to know the stage information" without questioning the
wisdom of that decision, especially as Linus and I were both in the
mindset to produce a small building-block to be used in a script
back then, and for a tool that deals with an unmerged index, having
the path alone is not all that useful.

But with time, we learn more needs out of our existing tools.