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

From: Guillaume Cogoni <cogoni.guillaume@gmail.com>
Date: Apr 25, 2022, 22:28 UTC
Message-ID: <CAA0Qn1u50ncejNtWs1AV5tcXjFC-jnmnvjFkBDQyqU4Wcvoy0g@mail.gmail.com>
In-Reply-To: <xmqqczh4vp6e.fsf@gitster.g>

 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.

We just make suggestions, we will think more about it.

> Wait.  Isn't it backwards?  The existing tests _may_ be casting an
> undesirable current behaviour in stone, but most of the time it is
> protecting existing user's expectations.  If you have an untracked
> file, you can rest assured that they won't be clobbered by a merge.

> So we'd need to think twice and carefully examine if it makes sense
> to update the expectations.  I haven't read the change to the tests,
> so I cannot tell which case it is.

Yes, we'll figure out a solution, if there is one.

Thanks for your review and your quick response, it give us a lot of information,

COGONI Guillaume and BRESSAT Jonathan