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