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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 18, 2022, 21:25 UTC
Message-ID: <xmqqv8wb6jhw.fsf@gitster.g>
In-Reply-To: <YjToDb9Mz9Q9z4Bq@camp.crustytoothpaste.net>

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

Show 14 quoted lines

> 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.