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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/26/22 00:28, Guillaume Cogoni wrote:
  Junio C Hamano <gitster@xxxxxxxxx> 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/



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux