# Overwriting untracked working tree files (when identical) 2 messages from 2008-11-29 to 2008-12-01. Participants: Asheesh Laroia, Andreas Ericsson. Thread: https://gitlist.dev/t/16522 ## Asheesh Laroia, 2008-11-29 18:58 Subject: Overwriting untracked working tree files (when identical) Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.00.0811290018340.15382%40vellum.laroia.net ``` I was using git earlier today and got the familiar error: "Untracked working tree file 'filename’ would be overwritten by merge" As it happens, I know that filename in my local filesystem and filename in the remote git branch have the same contents. Would it make sense for git to check for this possibility, and if the working tree file is the same as the file being merged in with that filename, allow the overwrite? (I received the message with "git pull," so I imagine it was emitted by the recursive merge driver.) -- Asheesh. -- Reply hazy, ask again later. ``` ## Andreas Ericsson, 2008-12-01 09:28 Subject: Re: Overwriting untracked working tree files (when identical) Message-ID: <4933AE45.4050400@op5.se> URL: https://gitlist.dev/e/4933AE45.4050400%40op5.se In-Reply-To: ``` Asheesh Laroia wrote: > I was using git earlier today and got the familiar error: > > "Untracked working tree file 'filename’ would be overwritten by merge" > > As it happens, I know that filename in my local filesystem and filename > in the remote git branch have the same contents. > > Would it make sense for git to check for this possibility, and if the > working tree file is the same as the file being merged in with that > filename, allow the overwrite? > That depends. git uses the work-tree to merge things. If one file is the same as that about to be written, it *might* make sense to clobber it, but what if it's identical to the expected merge-result? Git can't know that, but it's almost certainly a much saner approach than the other case, where the merge can go wahoonie-shaped at a later stage and thus require conflict resolution (which might well end up with the user getting fed up and doing "git reset --hard" to start over). For such cases, the file would appear to disappear, and that's a bad thing. Overall, I think it's best if this is left as-is. The code would be too complex for the gain it provides. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ```