# git merge error question: The following untracked working tree files would be overwritten by merge 3 messages from 2013-01-25 to 2013-01-26. Participants: Carsten Fuchs, Junio C Hamano. Thread: https://gitlist.dev/t/32724 ## Carsten Fuchs, 2013-01-25 10:37 Subject: git merge error question: The following untracked working tree files would be overwritten by merge Message-ID: <5102607E.2070106@cafu.de> URL: https://gitlist.dev/e/5102607E.2070106%40cafu.de ``` Hi all, in my repo, I'm doing this: > $ git status > # On branch master > # Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. > # > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # obsolete/ > nothing added to commit but untracked files present (use "git add" to track) > > $ git merge origin/master --ff-only > Updating f419d57..2da6052 > error: The following untracked working tree files would be overwritten by merge: > obsolete/e107/Readme.txt > obsolete/e107/article.php > obsolete/e107/backend.php > [...] That is, the local repository has the untracked directory "obsolete", which was added upstream as well, and now I try to reconcile. I seem to understand the problem stated in the error message, and the solution seems to be simple as well: renaming the obsolete/ directory is enough. But why does Git find a problem here at all? Compare with what Subversion did in an analogous case: When I ran "svn update" and the update brought new files for which there already was an untracked copy in the working directory, Subversion: - started to consider the file as tracked, - but left the file in the working-copy alone. As a result, a subsequent "svn status" might a) no longer show the file at all, if the foreign copy in the working directory happened to be the same as the one brought by the "svn update", or b) flag the file as modified, if different from the one that "svn update" would have created in its place. So my real question is, why does Git not do something analogous? (Afaics, update the HEAD, update the Index, but leave the working-copy edition alone?) I searched for this beforehand, and most advice involves either stashing, or with "git reset --hard" the loss of the untracked files. Sorry if this is a stupid question -- I still consider myself a Git learner. Best regards, Carsten ``` ## Junio C Hamano, 2013-01-25 18:07 Subject: Re: git merge error question: The following untracked working tree files would be overwritten by merge Message-ID: <7vehh95e7u.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vehh95e7u.fsf%40alter.siamese.dyndns.org In-Reply-To: <5102607E.2070106@cafu.de> ``` Carsten Fuchs writes: > Hi all, > > in my repo, I'm doing this: > >> $ git status >> # On branch master >> # Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. >> # >> # Untracked files: >> # (use "git add ..." to include in what will be committed) >> # >> # obsolete/ >> nothing added to commit but untracked files present (use "git add" to track) >> >> $ git merge origin/master --ff-only >> Updating f419d57..2da6052 >> error: The following untracked working tree files would be overwritten by merge: >> obsolete/e107/Readme.txt >> obsolete/e107/article.php >> obsolete/e107/backend.php >> [...] > ... > Compare with what Subversion did in an analogous case: When I ran "svn > update" and the update brought new files for which there already was > an untracked copy in the working directory, Subversion: > - started to consider the file as tracked, > - but left the file in the working-copy alone. > > As a result, a subsequent "svn status" might > a) no longer show the file at all, if the foreign copy in the > working directory happened to be the same as the one brought by the > "svn update", or > b) flag the file as modified, if different from the one that "svn > update" would have created in its place. Interesting. So before running "status", the merge is recorded (in this particular case you are doing ff-only so there is nothing new to record, but if the rest of the tree merges cleanly, the new tree that contains "obsolete" from the other branch you just merged will be the contents you record in the merge commit), and working tree is immediately dirty? It makes sense, even though I haven't tried to think things through to see if there are tricky corner cases. > So my real question is, why does Git not do something analogous? The answer to that question is "because nobody thought that doing so would help users very much and bothered to implement it"; it is not "people thought about doing so and found reasons why that would not help users". ``` ## Carsten Fuchs, 2013-01-26 10:46 Subject: Re: git merge error question: The following untracked working tree files would be overwritten by merge Message-ID: <5103B403.5010206@cafu.de> URL: https://gitlist.dev/e/5103B403.5010206%40cafu.de In-Reply-To: <7vehh95e7u.fsf@alter.siamese.dyndns.org> ``` Am 2013-01-25 19:07, schrieb Junio C Hamano: > Carsten Fuchs writes: >>> [...] >>> $ git merge origin/master --ff-only >>> Updating f419d57..2da6052 >>> error: The following untracked working tree files would be overwritten by merge: >>> obsolete/e107/Readme.txt >>> obsolete/e107/article.php >>> obsolete/e107/backend.php >>> [...] >> ... >> Compare with what Subversion did in an analogous case: When I ran "svn >> update" and the update brought new files for which there already was >> an untracked copy in the working directory, Subversion: >> - started to consider the file as tracked, >> - but left the file in the working-copy alone. >> >> As a result, a subsequent "svn status" might >> a) no longer show the file at all, if the foreign copy in the >> working directory happened to be the same as the one brought by the >> "svn update", or >> b) flag the file as modified, if different from the one that "svn >> update" would have created in its place. > > Interesting. So before running "status", the merge is recorded (in this > particular case you are doing ff-only so there is nothing new to > record, but if the rest of the tree merges cleanly, the new tree > that contains "obsolete" from the other branch you just merged will > be the contents you record in the merge commit), and working tree is > immediately dirty? Yes. But I don't think it's the (svn) "status" command that does anything special. In Git, if I understand it correctly, the final step of a "merge", "checkout", "reset", etc. is a move of the HEAD to the resulting or specified commit. I imagine that it is here where the diff of the dirty working tree is re-applied to the newly checked out commit (and if this is not possible cleanly, probably [a] the whole operation must abort, or [b] leave files in the working tree with conflict markers), and where a decision must be made about "obstructing paths" (svn lingo): [c] abort the whole operation, or [d] "version" them (but don't modify them in any way). I'm not sure if Subversion does [a] and [c] ("abort") without the --force option, and [b] and [d] with --force, or any other combination, but at least TortoiseSVN seems to use [d] by default (which seems safe enough). Despite a thorough search, I've not been able to find much reference about this behaviour: http://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.switch.html http://markphip.blogspot.de/2007/01/subversion-15-tolerate-obstructions.html However, as the blog article mentions, I too have found this treatment of obstructing paths very natural and helpful in several occasions. (Because without it, we must manually rename the obstructing paths, re-start the previously aborted operation, and then take diffs or somehow else compare the renamed obstructing and newly added paths manually, and possible merge them manually; or at least copy the renamed edition over the newly added edition to get back into Git for the job.) >> So my real question is, why does Git not do something analogous? > > The answer to that question is "because nobody thought that doing so > would help users very much and bothered to implement it"; it is not > "people thought about doing so and found reasons why that would not > help users". Thanks, it's very good to hear this! :-) Best regards, Carsten ```