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

From: Matthieu Moy <Matthieu.Moy@univ-lyon1.fr>
To: Guillaume Cogoni <cogoni.guillaume@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Cc: Jonathan <git.jonathan.bressat@gmail.com>,
	BRESSAT JONATHAN p1802864 <jonathan.bressat@etu.univ-lyon1.fr>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"guillaume.cogoni@gmail.com" <guillaume.cogoni@gmail.com>
Subject: Re: [PATCH v1 0/2] Be nicer to the user on tracked/untracked merge conflicts
Date: Tue, 26 Apr 2022 08:38:43 +0200	[thread overview]
Message-ID: <243b40ef-a720-46aa-6657-87ac8d3c3bdc@univ-lyon1.fr> (raw)
In-Reply-To: <fdd9f13d14e942f3a1572866761b9580@SAMBXP02.univ-lyon1.fr>

On 4/26/22 00:28, Guillaume Cogoni wrote:
>   Junio C Hamano <gitster@pobox.com> writes:
> 
>> So, I am not sure if this is really a good idea to begin with.  It
>> certainly would make it slightly simpler in a trivial case, but it
>> surely looks like a dangerous behaviour change, especially if it is
>> done unconditionally.
> 
> Can we create a configuration variable to avoid this problem?
> We keep the old behavior by default, and make a configuration variable
> for people who wants to have this new behavior, but if the user set the variable
> a message informs it about the problem that you mention.
> 
> Or, we add an option like git pull --doSomething.
> 
> Maybe, we can think about another behaviour.
> When the user git pull and this error occurs:
> error: The following untracked working tree files would be overwritten by merge:
> file1.txt
> file2.txt
> Please move or remove them before you merge.
> Aborting
> We don't abort, but we prompt a yes/no for each file, if the user
> wants to remove it.

Git very rarely goes interactive like this (only a few special command 
like git send-email, git clean -i, git add -i/-p prompt the user).

Prompting the user in the middle of an operation has several drawbacks:

- When the command is launched from a script, the script may work most 
of the time, and sometimes pause on an interactive prompt which wasn't 
expected from the author of the script. This can be a bit nasty when the 
script isn't ran from a place where you can type to the standard input 
of the command or when its output is redirected.

- Asking for each individual file can be tedious when there are many 
files. Similarly, "rm -i" (plain rm, not "git rm") is a nice safety 
measure, but not really convenient to me at least.

In this particular case, actually, I can't imagine a sane behavior when 
the user wants a mix of "yes" / "no". If a single untracked file 
conflicts with what's being merged, the merge aborts, even if you're OK 
to replace other files. So I can only imagine a single yes/no answer. 
And then the question can be replaced with a suggestion to re-run with a 
command-line flag when all the conflicting files are unmodified.

-- 
Matthieu Moy
https://matthieu-moy.fr/