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 track)
> $ git merge origin/master --ff-only
> Updating f419d57..2da6052
> error: The following untracked working tree files would be overwritten by
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
- 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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html