From: Junio C Hamano <gitster@pobox.com>
To: Carsten Fuchs <carsten.fuchs@cafu.de>
Cc: git@vger.kernel.org
Subject: Re: git merge error question: The following untracked working tree files would be overwritten by merge
Date: Fri, 25 Jan 2013 10:07:01 -0800 [thread overview]
Message-ID: <7vehh95e7u.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <5102607E.2070106@cafu.de> (Carsten Fuchs's message of "Fri, 25 Jan 2013 11:37:50 +0100")
Carsten Fuchs <carsten.fuchs@cafu.de> writes:
> 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 fast-forwarded.
>> #
>> # 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 merge:
>> obsolete/e107/Readme.txt
>> obsolete/e107/article.php
>> obsolete/e107/backend.php
>> [...]
> ...
> 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.
Interesting. So before running "status", the merge is recorded (in this
particular case you are doing ff-only so there is nothing new to
record, but if the rest of the tree merges cleanly, the new tree
that contains "obsolete" from the other branch you just merged will
be the contents you record in the merge commit), and working tree is
immediately dirty? It makes sense, even though I haven't tried to
think things through to see if there are tricky corner cases.
> So my real question is, why does Git not do something analogous?
The answer to that question is "because nobody thought that doing so
would help users very much and bothered to implement it"; it is not
"people thought about doing so and found reasons why that would not
help users".
next prev parent reply other threads:[~2013-01-25 18:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-25 10:37 git merge error question: The following untracked working tree files would be overwritten by merge Carsten Fuchs
2013-01-25 18:07 ` Junio C Hamano [this message]
2013-01-26 10:46 ` Carsten Fuchs
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=7vehh95e7u.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=carsten.fuchs@cafu.de \
--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).