Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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).
First, we think that add an option to pull and merge is more suited to
our situation, and next, it could be good to add the configuration
variable
In unpack-trees.c there is a list of files that cause problem with merge.
We want to split this list to list files that have the same content, then if
all the files have the same content, we can suggest to use the option
to overwrite those files.
Then we can modify the error message to show the files that have the
same content apart.
> 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.
We got a similar idea, but we finally decide that it was not a very good
approach because it's not efficient if we have a lot of files or some big files.
And because if there are files that doesn't block the merge, we treat them
anyway and they will move from the work tree, it's a bit overkill.
> 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.
Indeed, git stash works well with this kind of problem, however an option
would be easier in that specific case.
Thanks for you're helpfull review, you always give us a lot of good
information and ideas.
Cogoni Guillaume and
Bressat Jonathan
