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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 25, 2022, 23:10 UTC
Message-ID: <xmqqee1ku5ca.fsf@gitster.g>
In-Reply-To: <CAA0Qn1u50ncejNtWs1AV5tcXjFC-jnmnvjFkBDQyqU4Wcvoy0g@mail.gmail.com>

Guillaume Cogoni <cogoni.guillaume@gmail.com> writes:

Show 11 quoted lines

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

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

Show 9 quoted lines

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

I doubt this would fly as-is. Especially if the action that is offered by the prompt is "remove", not "move", as that implies we are not prepared against loss of information.

There is no indication whether the untracked file1.txt matches the contents we are pulling in. Most of the time, it is very unlikely that the contents being lost is identical to what the other side has, so answering "yes" to the prompt means "No, I do not care about my garbage, and it is OK that it will forever be lost." I do not think we want to be encouraging people to habitually make such a statement. If we move (instead of removing) them away to somewhere, and give users to easily recover them after running "git pull", it might become more palatable.

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.

Would "git stash push -u file1.txt file2.txt" be an easier and safer alternative that lets you take these files back later? Back in 2010, when 23cbf11b was current, "git stash" was a shell script and it seems there was no "untracked" option, so from that point of view, "move or remove" may have been the best they could do.

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.