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

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

[wuzhouhui]

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.

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

[Junio C Hamano]

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

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

Perhaps take "git jump" from contrib/ and do

    $ GIT_EDITOR=vi git jump merge

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

[Erik Cervin Edin]

On Fri, Mar 18, 2022 at 4:38 PM Junio C Hamano <gitster@pobox.com> wrote:
> Perhaps take "git jump" from contrib/ and do
>
>     $ GIT_EDITOR=vi git jump merge

This looks interesting. Thanks Junio

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

[wuzhouhui]

On 3/18/22 12:11, Junio C Hamano wrote:
> wuzhouhui <wuzhouhui14@mails.ucas.ac.cn> writes:
>
>> 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.
> Perhaps take "git jump" from contrib/ and do
>
>      $ GIT_EDITOR=vi git jump merge
Thanks everyone, The "git jump merge" satisfies my needs.

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

[Erik Cervin Edin]

On Fri, Mar 18, 2022 at 8:02 AM wuzhouhui <wuzhouhui14@mails.ucas.ac.cn> wrote:
>
> 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?
>

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 :/

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

[Junio C Hamano]

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

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

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On 2022-03-18 at 02:00:52, wuzhouhui wrote:
> 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?

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 (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Junio C Hamano]

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