From: Matthieu Moy Date: Tue, 26 Apr 2022 06:38:43 GMT Subject: Re: [PATCH v1 0/2] Be nicer to the user on tracked/untracked merge conflicts Message-ID: <243b40ef-a720-46aa-6657-87ac8d3c3bdc@univ-lyon1.fr> In-Reply-To: On 4/26/22 00:28, Guillaume Cogoni wrote: > Junio C Hamano 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/