Hi John,

Am 2013-01-11 14:15, schrieb John McKown:
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.

Thanks for your reply, but this is not the case here:

0. In my example, directory "obsolete/" was initially not in any repository, neither in a local nor the central upstream repository, nor in any working tree.

1. I started on computer A, where inside a working tree I initially created the directory "obsolete/" and its contents.

2. Then I sent (per SFTP, no Git involved) the complete directory "obsolete/" to computer B, into the working tree *there*, because I wanted to test something there before actually committing it on A. (Yes, there are facilities in Git that allow for alternative, more elegant solutions for such cases, but this time, this was what I had to do.)

3. On B, things worked out as expected, so I went back to A, added "obsolete/" to the repository ("git add obsolete/", "git commit"), and pushed the new commit upstream (to the central repository, on computer C).

4. Back on A (actually, all this was done via SSH logins to A and B...), I ran "git fetch" to obtain the new commit from the central repository C, then the "git status" that you've seen in my original mail.

5. The final "git merge origin/master --ff-only" failed. Although I saw solutions to the problem, it seems to me that Subversion works better in such cases, and thus I posted here. ;-)

Best regards,

On Fri, Jan 11, 2013 at 4:38 AM, Carsten Fuchs 
<carsten.fuchs-sdyparl0...@public.gmane.org> 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


   Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
          Learn more at http://www.cafu.de


Reply via email to