I'm not knowledgeable enough to answer your question. I do wonder why
you are not tracking the files in obsolete/ . If you truly don't want
to track them, then I _think_ that it might be well to add the line:
to your .gitignore file.
On Fri, Jan 11, 2013 at 4:38 AM, Carsten Fuchs <carsten.fu...@cafu.de> wrote:
> 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
>> # Untracked files:
>> # (use "git add <file>..." to include in what will be committed)
>> # obsolete/
>> nothing added to commit but untracked files present (use "git add" to
>> $ git merge origin/master --ff-only
>> Updating f419d57..2da6052
>> error: The following untracked working tree files would be overwritten by
> Well, I seem to understand the problem, 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.
> Best regards,
> Cafu - the open-source Game and Graphics Engine
> for multiplayer, cross-platform, real-time 3D Action
> Learn more at http://www.cafu.de