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

Hi

When "git rebase" stopped due to conflict, I have to manually open conflicted file one by one and resolve conflict, and the typing file path is too boring. So, how to automatically open (e.g. use Vim) conflicted files?

Thanks.

wuzhouhui <wuzhouhui14@mails.ucas.ac.cn> writes:

Perhaps take "git jump" from contrib/ and do

    $ GIT_EDITOR=vi git jump merge

On Fri, Mar 18, 2022 at 4:38 PM Junio C Hamano <gitster@pobox.com> wrote:

This looks interesting. Thanks Junio

On 3/18/22 12:11, Junio C Hamano wrote:

Thanks everyone, The "git jump merge" satisfies my needs.

On Fri, Mar 18, 2022 at 8:02 AM wuzhouhui <wuzhouhui14@mails.ucas.ac.cn> wrote:

Hi!

I rebase quite a lot and my strategy is as follows
  git diff
allows me to quickly overview the conflicted files and conflicts.
Usually, I want to either take all *ours* (the stuff I've rebased
onto) or *theirs* (the incoming rebased commit).

To do this quickly I've developed a script (basically glue-code of git => sed)
https://github.com/CervEdin/gut/blob/main/git-resolve.sh
which can be invoked
  git resolve -o/t/b (--ours/theirs/both) 'pathspec'
More information on the underlying implementation can be found in this
stackoverflow answer
https://stackoverflow.com/a/68498101/
The script is something I've developed for my own use and very much
not bug free.
Nevertheless, I personally find it efficiently covers the case of
basic conflicts I encounter.

In the situations of more complicated conflicts (as well as the
functionality you request) can be invoked using
  git mergetool
  git mergetool -- 'pathspec'
  git mergetool --tool=vimdiff -- 'pathspec'
That is unless you want to solely use vim without vimdiff.
The main downside is that invoking mergetool is a bit slow :/

Erik Cervin Edin <erik@cervined.in> writes:

Yeah, I forgot all about "git mergetool". I think that is the official answer to the original question.

On 2022-03-18 at 02:00:52, wuzhouhui wrote:

I agree that in the typical project with a few levels of directories this is a hassle.

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.

My approach also works less well if you have files with spaces or other characters special to the shell. That can be fixed with using NUL-terminated strings if that's a problem for you (it isn't on the projects I work on).

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

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.