Re: [PATCH v1 0/2] Be nicer to the user on tracked/untracked merge conflicts

From: Jonathan Bressat <git.jonathan.bressat@gmail.com>
Date: Apr 28, 2022, 10:33 UTC
Message-ID: <CANteD_zD9ViBi5woHycU_CR1rJcv7YjKDFDiKTA8de04yrTs5Q@mail.gmail.com>
In-Reply-To: <xmqq35hzsu0d.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

> Probably a command line option ("git merge" would probably want the
> same one) plus a configuration varaible to give it the default (the
> latter is optional).

First, we think that add an option to pull and merge is more suited to our situation, and next, it could be good to add the configuration variable

In unpack-trees.c there is a list of files that cause problem with merge. We want to split this list to list files that have the same content, then if all the files have the same content, we can suggest to use the option to overwrite those files. Then we can modify the error message to show the files that have the same content apart.

Show 8 quoted lines

> I wonder if this whole thing is an attempt to work around whatever
> "stash --untracked" fails to do well (or perhaps there are no such
> shortcomings, but just the users are not made aware of the command
> enough).  If you have these two untracked files (file1.txt and
> file2.txt) are "in the way" for a merge to succeed, I have to wonder
> if "Please move or remove" message that was introduced by 23cbf11b
> (merge-recursive: porcelain messages for checkout, 2010-08-11) is
> still giving a good piece of advice to users today.

We got a similar idea, but we finally decide that it was not a very good approach because it's not efficient if we have a lot of files or some big files. And because if there are files that doesn't block the merge, we treat them anyway and they will move from the work tree, it's a bit overkill.

Show 7 quoted lines

> Note that I never use "git stash" with "untracked" option, so I do
>  not know if it works well in this context already, or we need more
> work before it becomes usable in this scenario.  But it smells like
> it is exactly what we might want to use in such a situation to stash
> away these untracked file1.txt and file2.txt while running the
> merge, while allowing us to recover them after running the merge or
> discarding it.  I dunno.

Indeed, git stash works well with this kind of problem, however an option would be easier in that specific case.

Thanks for you're helpfull review, you always give us a lot of good information and ideas.

Cogoni Guillaume and Bressat Jonathan