Guillaume Cogoni <cogoni.guillaume@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.
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).
> 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.
