git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Swanny Lorenzi <swanny@jfg-networks.net>
To: git@vger.kernel.org
Subject: error: Untracked working tree file '(myfile)' would be overwritten by merge. when checking out a more recent branch
Date: Mon, 30 Jun 2008 12:15:56 +0200	[thread overview]
Message-ID: <4868B25C.1030005@over-blog.com> (raw)

Hi,

We got at work a surprising error when trying to checkout a more recent 
branch :
error: Untracked working tree file '(file)' would be overwritten by 
merge. (I replaced the actual file name by 'file' in this mail)

The context is :
- Each developer has its own git repository, and makes all developement 
work in it
- We use a "central" git repository to gather all our work, all devs 
track this common repository's branches to pull and push they work.
- We don't allow devs to track another dev branch, everything must pass 
by this central repository.
- We use git v 1.5.5.4, tig and git gui.
- Our main branch is called "trunk", and we use several other branches 
for our work.


Last Thursday, I had to replace 6 directories (with files in them) by 
symbolic links to another directory, in the "trunk" branch.
I removed them using sh rm -rf, then ln -s to create the links. Problem, 
git gui failed to stage the changes to a single commit.
I split the change into 2 operations : the directory removal -> commit, 
then the symlink creation -> commit.
I pushed the 2 commits - and other commits after - into our central 
repository, no error was prompted.

Then came the issue :
Each time a dev tried to checkout the trunk branch from an older version 
(e.g. a branch that has its origin to an older commit of trunk), he got 
the error message
error: Untracked working tree file '(file)' would be overwritten by merge.
=> Checkout failed, etc. Obliged to force the checkout with git checkout -f.

- The file listed in the error message is absolutely not affected by any 
commit in the 2 I mentioned above, nor in the 10 surrounding them. It 
was not even changed for 2 monthes.
- The error occur even if we don't have any "modified" file (git status 
answers nothing to commit, nor any untracked files)
- After investigations, it seems that the error occurs each time we ask 
git to run the 2 commits mentioned above in a single checkout command : 
If I checkout a branch pointing to the 1st commit (dir deletion), then 
another checkout to the trunk head, the error does not occur.
- The file mentioned in the error is the first file in the directory 
that follow the parent dir of the removed dirs (in the order returned by 
ls):

- I failed to reproduce this bug using clean repositories...

Has anyone got this error before ?
Is it a git bug ?

Thanks for all

Swanny

                 reply	other threads:[~2008-06-30 10:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4868B25C.1030005@over-blog.com \
    --to=swanny@jfg-networks.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).