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

"brian m. carlson" [off-list ref] 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.