All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.